SPF, DKIM, and DMARC Explained Like You Are Busy (But Want It Right)

Every deliverability problem eventually leads to the same three acronyms, and most explanations of them are written by DNS pedants for DNS pedants. Here is the version I give teammates: what each record actually tells the receiver, the mistakes that cause silent damage, and the order to roll them out so you do not block your own mail.

The one-sentence versions

• SPF publishes a list of IP addresses allowed to send for your domain. Receiver checks: is this server on the list?
• DKIM attaches a cryptographic signature to each message and publishes the public key in DNS. Receiver checks: was this message altered, and does the signature really belong to the domain?
• DMARC tells receivers what to do when the first two fail, and where to send you reports about it.

Think of it as ID, tamper-seal, and house policy. All three matter; none of them alone is enough.

The mistakes that do real damage

The SPF +all mistake. Records ending in +all mean “anyone can send for me,” which is the opposite of what you want; some providers flag the domain for it. Use -all or ~all depending on how confident you are.

Multiple SPF records. A domain may publish exactly one. Merging vendors means merging into a single record — two records invalidate both.

The ten-lookup limit. SPF evaluation allows at most ten DNS lookups. Every include: and every a/mx mechanism counts, nested includes count too. Big platforms can eat your entire budget; when you exceed ten, receivers are supposed to fail your SPF. Flatten carefully or drop includes you do not need.

DKIM key drift. Rotating providers without removing old keys is usually harmless, but changing selectors without re-signing produces validation failures nobody notices until opens drop. Keep selectors documented.

DMARC at p=reject on day one. You will quarantine your own legitimate mail the first time a vendor sends on your behalf unaligned. There is a right order: reports first, enforcement later.

The rollout order that works

1. Publish DKIM for every service that sends as you, and a single, minimal SPF record.
2. Publish DMARC at p=none with a rua= aggregate report address.
3. Collect reports for two to four weeks. Use a report parser — the raw XML is unreadable, the parsed summaries are enlightening. You will discover senders you forgot about.
4. Fix every legitimate source that fails alignment: missing includes, unaligned From domains, a vendor signing with their domain instead of yours.
5. Move to p=quarantine with a small percentage policy, watch a week, then p=reject once the reports are clean.

What “aligned” means, briefly

DMARC alignment is about the From domain you show users matching the domain that authenticated the message. A vendor sending from bounces.vendor.com with their DKIM does not align with your From address unless they sign with your domain or their SPF passes under your envelope domain. This subtlety is why every provider’s “domain authentication” setup step exists — do it for every tool you use, every time.

Where to start

Dig up every service that sends email as your domain — marketing platform, help desk, CRM, billing system, that cron script someone wrote in 2019 — and list them. Then walk the rollout order above. If you are mid-migration between providers, re-check these records first; half of all “switching providers broke my email” stories are really DNS stories. And remember that new domains need volume ramped gently regardless of perfect records — see our warmup guide. For the provider side of the equation, our four-platform comparison shows which ones make this setup painless.