RFCs

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

DMARC
Proposed Standard · 2026

RFC 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 reporting
Proposed Standard · 2026

RFC 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 reporting
Proposed Standard · 2026

RFC 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)
Informational · 2015 · 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)
Experimental · 2021 · 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 reporting
Proposed Standard · 2012

RFC 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 flows
Informational · 2016

RFC 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

SPF
Proposed Standard · 2014

RFC 7208 defines SPF — which servers may send for your domain, the ten-lookup limit, and every mechanism and modifier the syntax allows.

RFC 6376

DKIM
Internet Standard · 2011

RFC 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

ARC
Experimental · 2019

RFC 8617 defines ARC, which preserves authentication results across forwarders and mailing lists — the main reason legitimate mail fails DMARC.

RFC 8601

Authentication-Results
Proposed Standard · 2019

RFC 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 DKIM
Proposed Standard · 2018

RFC 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 lists
Best Current Practice · 2011

RFC 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)
Historic · 2009

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-STS
Proposed Standard · 2018

RFC 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-RPT
Proposed Standard · 2018

RFC 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 SMTP
Proposed Standard · 2015

RFC 7672 defines DANE for SMTP — publishing certificate constraints in DNSSEC-signed DNS, the alternative to MTA-STS for enforcing TLS.

RFC 3207

STARTTLS
Proposed Standard · 2002

RFC 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 Format
Draft Standard · 2008

RFC 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

SMTP
Draft Standard · 2008

RFC 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 unsubscribe
Proposed Standard · 2017

RFC 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.