SPF, DKIM, and DMARC, explained in plain English

If you run a business on your own domain, you’ve been told to “set up SPF, DKIM, and DMARC.” Nobody tells you what those actually do, so most people paste DNS records they don’t understand and hope. That works until something breaks, or until someone spoofs your domain and your customers get the invoice fraud.

Here’s the whole system in plain English: what each record does, a worked example for each, how the three chain together, and the mistakes that get good mail marked as spam.

SPF: the list of who’s allowed to send as you

SPF (Sender Policy Framework) is one DNS TXT record that answers a single question: which servers are allowed to send email claiming to be from this domain?

It looks like this:

v=spf1 include:_spf.google.com include:supermailos.com -all

Read it right to left: -all means “reject everything not on this list.” Each include: pulls in another provider’s server list, one for your mail host, one for your newsletter tool, and so on. When a receiver gets a message from you, it checks the connecting server against that list. On the list: pass. Not on it: fail.

Worked example: you send from Gmail but your invoice tool sends through its own servers. If the invoice tool’s servers aren’t in your SPF, those invoices fail authentication and start landing in spam. The fix is one include:, not a call to your customers.

The classic mistakes: two SPF records (as a pair they’re invalid; receivers see a permanent error and everything fails), and more than ten DNS lookups (the spec caps lookups at ten; past that, SPF hard-fails for everything). Keep the list short and honest.

DKIM: the signature that proves it’s really you

DKIM (DomainKeys Identified Mail) is a cryptographic signature your mail server adds to every outgoing message. The private key stays on the server; the matching public key goes in your DNS. Receivers verify the signature against that public key.

Because the signature covers the message body and key headers, DKIM proves two things SPF can’t: the message was sent by someone who holds your key, and nothing was tampered with in transit.

Worked example: a DNS record like selector._domainkey.yourcompany.com contains a long public key. Your server signs each message with the matching private half. When the signature verifies, receivers mark the mail as authenticated, and that pass feeds directly into DMARC.

The classic mistakes: publishing the DKIM record but never having the server actually sign (the record is just the public half; signing has to be enabled where mail leaves), and letting a key lapse after migrating providers. Both look identical from the outside: DKIM quietly failing on every message.

DMARC: the policy that ties them together

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the rulebook that sits above SPF and DKIM. It answers the question they can’t: when a message fails those checks, what should the receiver do about it?

It looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com

p= is the policy: none (monitor only: deliver, but send me reports), quarantine (spam-folder failures), or reject (drop them). rua= is where aggregate reports go. Those reports are the real prize. They show you every source sending as your domain: legitimate services you forgot to include, and spoofers you didn’t know about.

The right way to roll it out: start at p=none and read the reports for a couple of weeks. You will find a printer, a CRM, and a forgotten marketing tool sending as you. Add them or kill them, then step up to quarantine, then reject. Going straight to reject on day one is how companies silently lose their own order confirmations.

The classic mistake: publishing p=none forever. A monitoring-only policy doesn’t stop spoofing; it just tells you it’s happening.

How the three chain together

Think of it as three questions, asked in order:

1. SPF: did this come from a server I said could send for me?
2. DKIM: is this message genuinely from me, and untampered, provable by key?
3. DMARC: if either failed, what happens, and tell me who’s out there sending as me anyway?

One pass is enough for DMARC alignment (the domain in the visible From address has to match the one that passed SPF or DKIM). That’s why a forwarded message can survive: forwarding usually breaks SPF, but a valid DKIM signature carries through. The redundancy isn’t accidental; it’s the design.

And since February 2024 this isn’t optional polish at Gmail. Google’s sender guidelines require SPF or DKIM from everyone who sends to Gmail accounts, and SPF and DKIM and DMARC (p=none is enough) from anyone sending 5,000 or more messages a day.

Set all three up in under an hour

1. Inventory your senders. List every tool that sends email as your domain: mail host, CRM, support desk, invoicing, marketing. Miss one and its mail fails once you enforce.
2. Publish SPF. One record, one include: per real sender. End it with ~all while you’re setting up and -all once you’re sure the list is complete. Delete any old duplicate first.
3. Enable DKIM. In each sending tool, turn on DKIM and publish the DNS records it hands you. Verify with a test send.
4. Publish DMARC at p=none. Point rua at an address you actually read.
5. Verify on a real message. Send one to a Gmail and an Outlook account and read the SPF, DKIM and DMARC results in its headers (Gmail’s “Show original”). A fail here is almost always a copy-paste slip, and cheap to fix now.
6. Read the reports, then enforce. Two weeks of p=none, fix what the reports surface, then quarantine → reject.
7. Keep reading them. Once a week is enough: you’re looking for senders you don’t recognise and for drops in your own pass rate, which usually mean a tool changed how it sends.

Before you touch DNS, see where you stand: the free email checker looks up your SPF, DKIM, DMARC, MX, and MTA-STS records and explains any gaps in plain English.

What changes when you run several domains?

Everything above runs once per domain: each needs its own SPF record, its own DKIM key and its own DMARC policy. The usual gap is the quiet domain left at p=none for a year, still reporting spoofing without stopping any. Keep a short list of every domain, its current DMARC policy and when you last read its reports.

Or skip the DNS homework entirely

This is legitimately the boring part of running business email, and it’s the part SuperMailOS does for you: bring your domain and its SPF, DKIM and DMARC records are generated from the mail server’s own zone and checked live before the domain can send. They’re written for you in one click on Cloudflare, DigitalOcean, Linode, Vultr, Hetzner DNS and Spaceship, and DMARC reports are parsed into a per-domain dashboard instead of XML attachments. Plans start at $4 per mailbox per month on the pricing page, with a 14-day free trial and no card required.

Sources

• RFC 7208 (SPF), RFC 6376 (DKIM) and RFC 7489 (DMARC).
• Google’s email sender guidelines, for the Gmail requirements.

Questions

Back to all guides.