If you've ever added a DNS record for email and had no real idea what it did, you're not alone. SPF, DKIM, and DMARC show up together in almost every "set up your email" guide, usually with no explanation of how they relate. They're not three versions of the same thing: they solve three different problems, and DMARC, the one most people are actually trying to set up, doesn't work at all without the other two. Here's what each one actually checks.
SPF: "Is this server allowed to send for you?"
SPF (Sender Policy Framework) is a DNS record (just a line of text) that lists every mail server allowed to send email as your domain:
v=spf1 include:_spf.google.com include:sendgrid.net -all
When someone receives a message claiming to be from example.com, their mail server checks this list. If the message didn't come from a server on it, the -all at the end says to reject it outright. (You'll sometimes see ~all instead. That's the soft version, more of a warning label than a lock, and worth tightening once you're confident your record covers everything you actually use.)
Here's the catch: SPF checks the address used behind the scenes during delivery, not the "From" address a person actually sees in their inbox. Those two don't have to match: a message can pass SPF completely and still show a different domain to the recipient. SPF has no opinion on that at all.
DKIM: "Was this message tampered with along the way?"
DKIM (DomainKeys Identified Mail) takes a different approach. Instead of checking where a message came from, it checks whether the message was changed after it was sent. The sending server attaches a digital signature, and the matching public key lives in your DNS:
default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
The receiving server checks the signature against that key. If it matches, two things are confirmed: nothing was altered in transit, and the message really was signed by whoever controls that DNS record. You can have several of these at once (one for Google Workspace, one for your marketing platform, one for your support tool) since each service signs under its own name.
DKIM's blind spot is the mirror image of SPF's: a signature can be completely valid for the domain that actually signed it, while the visible From address claims to be someone else entirely. DKIM never checks whether those two match.
Neither SPF nor DKIM look at the display name, the friendly label like "Your Company" in front of the actual address. That's a separate problem none of these three tools touch.
DMARC: "Do SPF or DKIM actually match what the recipient sees?"
This is the part people get wrong most often: DMARC doesn't do its own verification. It doesn't check servers, and it doesn't check signatures: it checks whichever of SPF or DKIM passed, and compares that against the domain in the "From" address the recipient actually sees.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
A message passes DMARC if either SPF or DKIM passes and lines up with the visible From domain. That's the gap it closes: a message can pass SPF, pass DKIM, and still be spoofing the address a person is looking at, because neither check on its own compares itself to what's on screen. DMARC is the piece that ties everything back to what the recipient actually trusts.
The p= tag tells mailbox providers what to do with mail that fails: none (deliver it anyway, just tell you about it), quarantine (send it to spam), or reject (bounce it). The rua= tag is what makes this genuinely useful day to day: it tells every participating mailbox provider to send you a daily report of everything they saw claiming to be from your domain, pass or fail, and where it came from.
Why you need all three
- SPF without DKIM breaks the moment a message gets forwarded: forwarding usually changes the server it's coming from, so SPF fails at the next hop.
- DKIM without SPF holds up a bit better, but not always: a mailing list or forwarder that edits the subject line or adds a footer breaks the signature just the same.
- Either one without DMARC leaves your actual From address unprotected, which is the one thing your recipients are looking at.
If you're setting this up for the first time: get SPF and DKIM in place for everything that sends on your behalf, then add a DMARC record at p=none. That alone gets you visibility into exactly who's sending mail as your domain, before you block anything. Treat p=none as a starting point, not the destination: once your reports go quiet for everything you don't recognize, move to quarantine, then reject, so a spoofed message actually gets stopped instead of just logged.
That visibility is where most people get stuck, because those reports arrive as gzipped XML files nobody wants to open by hand. MyDMARC turns them into a plain dashboard: every sending source, whether it's passing, and how close you are to being ready for a stricter policy, no technical expertise required. And once your records are live, OneDollarDNS will tell you the moment any of them change without warning, for a dollar a month per domain, cheap insurance against a broken record nobody notices for weeks.