How the mail system arrived at needing these three at all is the subject of the email lineage.

The original sin

(Simple Mail Transfer Protocol) has no sender authentication. Any server can claim to be sending on behalf of any domain, and the protocol will happily carry it. Everything below is retrofitting.

The retrofit is confusing for one structural reason: a message has two "from" addresses. The envelope sender is what the sending server declares during the SMTP conversation and is where bounces go. The header From is what the recipient actually sees in their mail client. They can legally differ, they routinely do for legitimate reasons, and the gap between them is exactly where spoofing lives.

Keep that distinction in mind and the three records stop being interchangeable acronyms.

SPF: which servers may send

(Sender Policy Framework) is a DNS record listing the addresses permitted to send mail for a domain. The receiving server compares the connecting address against the list and gets a pass or fail.

What it checks is the envelope sender, not the visible From. That is the single most misunderstood fact in this area: a message can pass SPF perfectly while displaying any From address it likes.

Its practical limits are worth knowing before you rely on it. Evaluation is capped at ten DNS lookups, and every include: of a large provider consumes them, so sprawling records silently fail rather than fail loudly. And forwarding breaks it: when a recipient forwards mail, the forwarding server is not on your list, so SPF fails through no fault of anyone involved.

DKIM: was the message altered, and by whom

(DomainKeys Identified Mail) signs selected headers and the body with a private key; the public key lives in DNS. A receiver verifies the signature and learns that a particular domain took responsibility for the message and that the signed parts were not modified in transit.

Because the signature travels with the message, DKIM survives simple forwarding, which is where SPF fails. It also does not, by itself, say anything about the visible From: a valid signature from one domain can accompany a message displaying another.

Two operational notes: keys need rotation like any other key material, and the optional body-length tag lets a signature cover only the first part of a body, which allows content to be appended below a valid signature. Do not use it.

DMARC: the one that ties it together

(Domain-based Message Authentication, Reporting and Conformance) adds the missing piece: alignment. It requires that a passing SPF or DKIM result belong to the same domain the reader sees in the From field. That is the actual protection, and neither SPF nor DKIM provides it alone.

DMARC first appeared in March 2015 as (RFC) 7489, an Informational document published through the Independent Submissions Editor rather than any Internet Engineering Task Force work stream. Since May 2026 it is a Standards Track protocol, RFC 9989, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991, and the three obsolete RFC 7489 (RFC 9989, Appendix C.1; RFC Editor, RFC 7489). Guides written before then describe the 2015 text.

It also does two things people underrate:

It publishes a policy (none, quarantine or reject) telling receivers what to do with unaligned mail claiming your domain.

It asks for reports. Aggregate reports arrive from receivers describing what passed and failed for your domain, from which addresses. Their format is the one RFC 9990 defines, and a receiver sends them only when the record names an address in its rua tag (RFC 9989, section 4.7). This is the part that makes deployment possible, and it is free intelligence about who is sending as you, including your own forgotten systems and anyone forging you.

Why almost everyone stalls at p=none

The honest deployment path is not the one that gets recommended in a single sentence.

  1. Publish SPF and DKIM properly, then DMARC at p=none. Nothing is blocked yet.
  2. Read the reports for weeks. You will find legitimate senders nobody told you about: the invoicing system, the marketing platform, the ticketing tool, a branch office relay.
  3. Fix or authorise each one. This is the real work, it is organisational rather than technical, and it is where projects die.
  4. Move to quarantine, then reject, one step at a time, comparing the reports at each.

RFC 9989 puts numbers on that patience for any domain whose users post to mailing lists: publish p=none "for at least a month", then p=quarantine for an equally long period, and compare the results before thinking of p=reject, which it advises such domains not to publish at all (RFC 9989, section 7.4). A domain that does publish p=reject "MUST apply valid DKIM signatures to their messages", because forwarding breaks SPF (section 7.4). The percentage rollout that older guides recommend is gone: RFC 9989 removed the pct tag, because receivers usually applied it accurately only at 0 and 100, and kept its useful half as the t tag, for testing, where t=y asks receivers to apply one level below the published policy, none instead of quarantine and quarantine instead of reject (Appendices A.6 and C.5.2, section 4.7).

Organisations sit at p=none for years because step 3 requires finding every system that sends mail as the company, in a company where nobody has that list. Publishing p=reject before finishing it means blocking your own invoices.

What breaks it in the real world

Forwarding breaks SPF, as described. Mailing lists often break DKIM too, because they modify subject lines or append footers, invalidating the signature.

(Authenticated Received Chain), described in RFC 8617, was built for this: an intermediary records the authentication results it saw and signs that record, so a later receiver can see that mail failed only because a trusted forwarder handled it. It has not taken hold. RFC 9989 records that after a decade of attempts to let mailing lists work without touching the From line, with ARC as the prominent example, "none of the methods have become widely used" (RFC 9989, section 7.4), and ARC also requires trusting the intermediary's assertion. What works in practice is the workaround: list software rewrites the From line, to the list's own address or to a reversible form of the author's, so that it aligns, and RFC 9989 calls these workarounds "firmly established" (section 7.4).

What it does not protect against

This is the part that gets oversold, so state it plainly:

  • Lookalike domains. DMARC on yourcompany.com does nothing about yourc0mpany.com. Attackers register their own domain and authenticate it perfectly.
  • Display-name spoofing. A message from a random address showing the display name of your chief executive passes everything, because nothing here authenticates a human-readable name.
  • Compromised legitimate accounts. Mail sent from a real, hijacked mailbox is authentic by every measure these standards apply.

The accurate summary: these standards stop others from sending as your domain. They do not stop your users from being phished. That second problem needs different controls, and conflating the two is how organisations end up believing an authentication project made them safe.

Neighbours often confused with these

-STS and DANE secure the transport: they make sure mail to your domain travels over verified TLS rather than being downgraded. That is confidentiality and integrity in transit, a different problem from authenticating the sender. BIMI displays a brand logo in supporting clients and requires DMARC enforcement, which makes it, in practice, a commercial incentive to finish the work above.

The short checklist

  • One SPF record, under the lookup limit, with no +all.
  • DKIM signing on every sending system, keys rotated, no body-length tag.
  • DMARC at p=none with an aggregate report address, on day one.
  • A named owner for the reports, because unread reports are the same as no reports.
  • A written inventory of everything that sends mail as you, the artefact the whole project is really about.
  • Enforcement when, and only when, that inventory is complete.

Sources