What each standard does, why you need all three, and the right order to set them up - from a contributor to the RFCs that define DMARC.
Why Email Authentication Exists
Email was designed in an era of trust, with no built-in way to prove a message really came from the domain it claims. SPF, DKIM and DMARC are the three standards that close that gap. Together they let a receiving server verify that a message is genuinely authorized by the domain in the From address - and they are now required by Gmail, Yahoo and Microsoft for bulk senders.
I was named as a contributor to RFC 7489, the original IETF specification for DMARC, and its successor RFC 9989. This guide is the plain-English version of what those documents define.
SPF: Who Is Allowed to Send
Sender Policy Framework (SPF) is a DNS TXT record listing the mail servers authorized to send for your domain. The receiving server checks it against the message's return-path (the hidden bounce address, not the visible From). If the sending server is not listed, SPF fails.
SPF alone is fragile: it breaks on forwarding, and it validates the return-path rather than the address your recipient actually sees. That is why it is one leg of a tripod, not the whole solution. See the detailed SPF guide.
DKIM: A Tamper-Proof Signature
DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to each message, using a private key held by the sender and a public key published in DNS. The receiver recomputes the signature; if it matches, the message is proven to come from the signing domain and to have not been altered in transit. Unlike SPF, DKIM survives most forwarding. See the detailed DKIM guide.
DMARC: Tying It Together and Telling Senders What to Do
DMARC builds on SPF and DKIM by adding two things: alignment (the authenticated domain must match the visible From domain) and a policy you publish telling receivers what to do with mail that fails - none, quarantine, or reject. Crucially, DMARC also sends you aggregate reports, so for the first time you can see who is sending mail as your domain.
The recommended path is to start at p=none to observe, fix every legitimate source until it aligns, then move to p=quarantine and finally p=reject. See the DMARC guide, the migration guide, and how to read a DMARC report.
The Order to Set Them Up
Publish SPF first, then DKIM, confirm both pass and align, then publish DMARC at p=none and read the reports before tightening. Rushing to p=reject before every legitimate sender aligns is the single most common way senders accidentally block their own mail.
Frequently Asked Questions
What is the difference between SPF, DKIM and DMARC?
Do I need all three?
Is DMARC required in 2026?
Who created DMARC?
Emails landing in spam?
Henry Timmes diagnoses why your mail isn't reaching the inbox - Microsoft 365, Gmail, Yahoo and beyond - and maps a practical fix. Book a free 15-minute call, no obligation.
Book a free consultation