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 (they’re invalid as a pair — 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 2024, this isn’t optional polish. Gmail and Microsoft require SPF and DKIM and DMARC for bulk senders, and they apply the expectations to everyone else too. Missing records aren’t neutral anymore; they’re a spam signal.

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, ending -all. 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. Read the reports, then enforce. Two weeks of p=none, fix what the reports surface, then quarantine → reject.

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.

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 SPF, DKIM, and DMARC are generated, published, and monitored — with DMARC reports parsed into a 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. Back to all guides.