Anyone can put your domain in an email’s From line — SPF, DKIM, and DMARC are the three DNS records that let receiving servers tell your real mail from the impostors. Gmail and Yahoo started requiring them in 2024, Microsoft followed in 2025, and enforcement has only tightened since: unauthenticated mail now gets rejected outright, not just filed under spam. If your invoices or contact-form messages have gone quiet, start here. You’ll need DNS access and comfort editing records — these are all TXT records, the safe kind, but a typo in SPF can bounce your own mail, so go carefully.

Inventory everything that sends as your domain

Before writing any record, list every service that puts your domain in a From address: your mail provider (Google Workspace, Microsoft 365), the website’s contact form or transactional sender (SendGrid, Postmark, SMTP plugin), the newsletter tool, the invoicing app, the CRM. Check the website especially — a store or contact form is a sender people forget. Miss one here and you’ll accidentally declare your own mail fake later, so take the full ten minutes.

Publish an SPF record that covers all of it

SPF is one TXT record at the root of your domain naming every service allowed to send for you. Each service’s docs give you an include:; chain them together:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Two rules. First, exactly one SPF record — a second one doesn’t add, it breaks both. Second, SPF allows at most 10 DNS lookups, and every include spends some; if you’re stacking five services, check your record with an SPF checker before publishing. The ~all at the end means “treat anything else as suspect.”

Turn on DKIM signing at each sender

DKIM is a cryptographic signature each service stamps on its outgoing mail; you publish the matching public key in DNS. There’s no shared record here — each sender from your inventory has its own switch, usually under “authenticate your domain” or “DKIM” in its settings. The service generates the key (choose 2048-bit where asked), hands you a CNAME or TXT record, and verifies it once you’ve added it. Work down your list until every sender shows verified.

Add a DMARC record in monitor mode

DMARC is the policy tying it together: what receivers should do with mail that fails, and where to send you reports. Start in monitor mode — it changes nothing about delivery yet, it just starts the mail flowing about your mail. One TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

p=none means “report, don’t punish.” Use a real mailbox you can read, or better, a free report-digest service (Postmark’s DMARC digests, dmarcian’s free tier) — the raw reports are zipped XML, and nobody should read zipped XML on purpose.

Read a week of DMARC reports

Let a full week of mail flow, then read the digests. You’re looking for one thing: legitimate senders failing authentication. A forgotten invoicing app, a form plugin sending from the server directly — each one goes back through steps two and three until the reports show your real mail passing everywhere and the only failures are strangers pretending to be you. Those failures are the system working.

Tighten the policy once the reports are clean

With a clean week behind you, change p=none to p=quarantine (failures go to spam), wait another clean week, then p=reject (failures bounce). That final record is what actually stops spoofing. Verify the whole stack: send yourself a Gmail message from each sender, open it, choose “Show original,” and look for three green PASSes — SPF, DKIM, DMARC. Three passes from every sender on your list, and your mail is carrying proper ID. Deliverability follows the proof.