Email was designed in an era of implicit trust, so by default anyone can send a message claiming to be from your domain. SPF, DKIM and DMARC are the three DNS records that close that gap. Together they let receiving servers verify that a message genuinely came from you and decide what to do when it did not.
They are often described as interchangeable. They are not — each answers a different question, and DMARC only works once the other two are in place.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a TXT record listing the servers permitted to send mail for your domain. When a receiver gets a message, it checks the sending server's IP against your SPF record.
example.com. IN TXT "v=spf1 include:_spf.google.com include:mailgun.org -all"
- include: pulls in the sending IPs of a provider such as Google Workspace or Mailgun.
- ip4:/ip6: authorise specific addresses you send from directly.
- -all means "reject anything not listed" (a hard fail); ~all is a softer "mark as suspicious".
SPF has a hard limit of 10 DNS lookups. Chaining too many include: mechanisms breaks the record and causes a permerror — one of the most common silent SPF failures.
SPF has a blind spot: it validates the hidden envelope sender, not the "From:" address the user actually sees. It also breaks when mail is forwarded, because the forwarding server's IP is not in your record. That is where DKIM comes in.
DKIM: proof the message was not tampered with
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. Your mail server signs the message with a private key; the matching public key lives in a DNS TXT record at a "selector" subdomain. The receiver fetches the public key and verifies the signature.
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...AQAB"
A valid signature proves two things: the message really came from your domain, and its signed content was not altered in transit. Crucially, DKIM survives forwarding — the signature travels with the message — which is exactly where SPF falls down.
DMARC: the policy that ties it together
SPF and DKIM each produce a pass or fail, but on their own they do not tell receivers what to do with a failure, and they do not check the visible "From:" address. DMARC (Domain-based Message Authentication, Reporting and Conformance) fixes both problems.
example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"
DMARC introduces "alignment": it requires that the domain validated by SPF or DKIM matches the domain in the visible From: address. This is what actually stops someone from spoofing your From: line even if they pass SPF on some unrelated domain.
The three policies
- p=none — monitor only. Nothing is blocked, but you receive reports. Always start here.
- p=quarantine — failing mail goes to spam.
- p=reject — failing mail is refused outright. This is the goal for a locked-down domain.
The rua address is where aggregate XML reports are sent. These reports are the single most useful part of DMARC: they show you every source sending mail as your domain, so you can spot both legitimate services you forgot about and outright abuse before you tighten the policy.
A safe rollout order
- Publish SPF listing every legitimate sending service. Verify it stays under 10 lookups.
- Enable DKIM signing on every service that sends as your domain, and publish each public key.
- Publish DMARC with p=none and a rua address. Collect reports for a few weeks.
- Once reports confirm all legitimate mail aligns, move to p=quarantine, then finally p=reject.
Jumping straight to p=reject before reading DMARC reports is the fastest way to silently block your own invoices, password resets and newsletters. Monitor first.