After eleven years, DMARC is a real standard: RFC 9989, 9990, and 9991 replace RFC 7489. What is different, what stays, and the short list of actions for senders.
It is official. On May 21, the IETF published DMARCbis as three Standards Track documents: RFC 9989 carries the core authentication-and-policy protocol, RFC 9990 the aggregate reporting, and RFC 9991 the failure reporting. Together they obsolete RFC 7489, ending DMARC's eleven-year run as an Informational document that the entire industry treated as a standard anyway. When we covered DMARCbis last September it was approved and queued; now it has numbers, and the compliance world can start citing them.
What the split means
One document became three along the protocol's natural seams. RFC 9989 is what most people mean by DMARC: policy discovery, alignment, dispositions, the record syntax. RFC 9990 specifies the aggregate reports your parsedmarc pipeline consumes, now maintained independently so reporting can evolve without reopening the core. RFC 9991 documents failure reporting, the per-message ruf mechanism that most large receivers declined to send for privacy reasons, now specified cleanly for the receivers that do. For implementers the split clarifies ownership; for senders it changes citations and nothing else.
The technical changes, now official
Everything previewed in our September piece is now the published standard. The DNS tree walk replaces the Public Suffix List for finding the organizational domain, moving the boundary authority into DNS itself with psd= marking public suffix operators. The pct tag is retired, its percentage-rollout promise having never survived contact with inconsistent receiver implementations. The np tag is standard: a policy for non-existent subdomains, letting a record refuse mail from fabricated names while real subdomains stay at a gentler policy. And v=DMARC1 remains the version string, because backward compatibility was a design requirement: every valid record published in the last decade keeps working unmodified.
Why Standards Track matters beyond ceremony
Informational RFC 7489 always carried an asterisk in formal contexts: the thing every provider mandated was, technically, a description of an industry practice. RFC 9989 removes the asterisk. Compliance frameworks, government guidance, and security questionnaires cite standards, and the citation chain updates fast: expect NIS2-adjacent audit checklists, procurement templates, and vendor questionnaires to reference 9989 within the year. For teams that fought internal battles to fund DMARC enforcement, the standard's new status is retroactive ammunition, and for the holdouts, the have you deployed the standard conversation just lost its last technicality.
The sender to-do list
Short, and mostly familiar
- 1
Delete pct where it lingers
Retired in the standard, inconsistently honored before it. A record still carrying pct= is advertising an unfinished rollout; finish it with the monitored policy progression.
- 2
Plan np= adoption
np=reject on non-existent subdomains is low-risk hardening as receiver support spreads: fabricated names send no legitimate mail by definition.
- 3
Update your documents
Internal runbooks, security-questionnaire boilerplate, and customer-facing trust pages that cite RFC 7489 now cite RFC 9989 (and 9990 for reporting). Cosmetic, and someone will notice if you skip it.
- 4
Change nothing operational
The monitoring loop, the aggregate report triage, the enforcement policies: all continue exactly as the archive describes. Publication formalized the practice; it did not revise it.
There is a quiet milestone inside the bureaucratic one. DMARC began as a private industry agreement published for information, spent a decade becoming universal practice, survived a mandate era that made it mandatory infrastructure, and only then became a formal standard, the reverse of how standards are supposed to work and exactly how the successful ones actually do. The paperwork finally matches the world. That is worth a small toast at the next deliverability standup, and then it is back to reading aggregate reports, which RFC 9990 now officially blesses as the way this all stays observable.
Frequently Asked Questions
Do I need to change v=DMARC1 in my records?
Does RFC 9991 mean failure reports will start flowing again?
When will receivers complete the tree-walk migration?
Does the new standard change the provider mandates?
Key Takeaways
- RFC 9989, 9990, and 9991 are published, obsoleting RFC 7489 and making DMARC a Proposed Standard after eleven years
- Existing v=DMARC1 records keep working; backward compatibility was a design requirement
- The tree walk, pct retirement, and np tag are now official, exactly as previewed during the approval phase
- Sender actions: drop lingering pct tags, plan np adoption, update documents citing 7489
- Standards Track status feeds the compliance citation chain; operations continue unchanged
Related articles
Half-Year Review: Email in the AI Inbox Era
Six months that rearranged the reading layer: Gemini in Gmail, Microsoft rejecting outright, DMARC finally a standard. What the first half of 2026 means for senders.
Subaddressing: What Plus Addresses Tell Senders
user+anything@gmail.com is one mailbox wearing labels. How subaddressing works, why blocking it backfires, and what plus addresses reveal about your data flows.
Rebrand Migrations: Moving Email Identity to a New Domain
A rebrand replaces the one asset deliverability cannot: your domain's history. The parallel-running plan that carries trust from the old name to the new one.