The specifications, and which ones still apply.
Email authentication is defined across a dozen documents of varying age and status. This is what each one governs and how they fit together.
DMARC was re-specified in 2026
If you are looking for the DMARC RFC, the answer changed recently. RFC 7489 — the document nearly every article and vendor page still cites — is obsolete. It was replaced by three documents, because the protocol and its two report formats can now evolve independently:
- RFC 9989 — the protocol. Also the first time DMARC has been on the standards track at all.
- RFC 9990 — aggregate reports, the XML your
rua=address receives. - RFC 9991 — failure reports, requested with
ruf=.
Practically, most records need no change: the syntax barely moved. The
exceptions are pct, rf and ri,
which are now historic — what changed in RFC 9989
covers the replacement for each.
DMARC
The protocol and its two reporting formats. Replaced RFC 7489 in 2026.
RFC 9989
DMARCRFC 9989 is the current DMARC standard, replacing RFC 7489 in 2026. What the document covers, the tag registry as it stands, and where to read what changed.
RFC 9990
DMARC aggregate reportingRFC 9990 specifies the DMARC aggregate report — the XML your rua address receives. Split out of RFC 7489, with a clarified schema and required DKIM selectors.
RFC 9991
DMARC failure reportingRFC 9991 specifies DMARC failure reports — the per-message detail ruf requests. Split from RFC 7489, and the reason almost nobody sends them.
RFC 7489
DMARC (superseded)RFC 7489 was the original DMARC document. It is obsolete — replaced in 2026 by RFCs 9989, 9990 and 9991. Here is what to cite instead.
RFC 9091
PSD DMARC (superseded)RFC 9091 was the experimental extension letting public suffix operators publish DMARC for domains beneath them. It is now folded into RFC 9989.
RFC 6591
ARF failure reportingRFC 6591 defines the Abuse Reporting Format extension that DMARC failure reports are built on, and the fields a failure report carries.
RFC 7960
DMARC and indirect mail flowsRFC 7960 catalogues why legitimate mail fails DMARC — mailing lists, forwarders and gateways — and which of those problems have no clean fix.
Authentication
The mechanisms DMARC is built on, plus the one that patches forwarding.
RFC 7208
SPFRFC 7208 defines SPF — which servers may send for your domain, the ten-lookup limit, and every mechanism and modifier the syntax allows.
RFC 6376
DKIMRFC 6376 defines DKIM — the cryptographic signature on outgoing mail, the selector that names the key, and what a signature does and does not prove.
RFC 8617
ARCRFC 8617 defines ARC, which preserves authentication results across forwarders and mailing lists — the main reason legitimate mail fails DMARC.
RFC 8601
Authentication-ResultsRFC 8601 defines the Authentication-Results header — where dmarc=pass, spf=fail and dkim=pass come from, and how to read one correctly.
RFC 8463
Ed25519 for DKIMRFC 8463 adds Ed25519 signatures to DKIM — much shorter keys that fit DNS comfortably, and why almost nobody uses them alone.
RFC 6377
DKIM and mailing listsRFC 6377 is the best-current-practice document for running a mailing list without breaking DKIM — written before DMARC made the problem worse.
RFC 5617
ADSP (historic)RFC 5617 defined ADSP, DMARC's failed predecessor. Its status is Historic, and understanding why explains most of DMARC's design.
Transport security
Protecting mail in transit — a different problem from who may claim your domain.
RFC 8461
MTA-STSRFC 8461 defines MTA-STS — how a domain declares that inbound mail must arrive over authenticated TLS, and how senders discover and cache that policy.
RFC 8460
TLS-RPTRFC 8460 defines TLS-RPT — daily JSON reports on whether mail to your domain arrived over TLS, and why any of it failed to.
RFC 7672
DANE for SMTPRFC 7672 defines DANE for SMTP — publishing certificate constraints in DNSSEC-signed DNS, the alternative to MTA-STS for enforcing TLS.
RFC 3207
STARTTLSRFC 3207 defines STARTTLS, which encrypts mail in transit — and is trivially stripped, which is the problem MTA-STS and DANE exist to solve.
Message and envelope
The two addresses DMARC exists to reconcile, and one bulk-sender requirement that arrived beside it.
RFC 5322
Internet Message FormatRFC 5322 defines the message format itself — including the From header that DMARC aligns against, and why it is distinct from the envelope sender.
RFC 5321
SMTPRFC 5321 defines SMTP and the envelope — including the MAIL FROM address that SPF checks, which is not the From header your recipient sees.
RFC 8058
One-click unsubscribeRFC 8058 defines one-click unsubscribe — a requirement for bulk senders at Google and Yahoo since 2024, alongside DMARC.
BIMI is not an RFC
Worth stating plainly, because it is asked constantly and most sources
are vague about it: there is no BIMI RFC. Brand
Indicators for Message Identification exists as an IETF Internet-Draft
(draft-brand-indicators-for-message-identification) and has
never been assigned an RFC number — checked against the IETF datatracker,
not inferred.
That does not make it unreal. BIMI is deployed, several large mailbox providers honour it, and it has a working specification. It simply is not a standard, which is why implementations differ on details like certificate requirements. See BIMI for what it does and what it needs from your DMARC policy.
Also worth knowing
Two more have no page here. RFC 8616 extends email authentication to internationalized addresses, and RFC 8689 defines REQUIRETLS, which lets an individual message demand TLS rather than a domain declaring a policy for all of them.
How these were checked
Every number, title, status and obsoletes relationship on these pages was taken from the RFC Editor's own metadata rather than from secondary sources — which matters more than usual here, because RFC 7489 was replaced by three documents and a lot of material published since gets that wrong.