For over a decade, DMARC lived in a single document: the informational RFC 7489. That changed when the IETF's DMARC working group — informally known as "DMARCbis" — finished splitting the specification into three separate Standards Track RFCs. If you manage a domain's email authentication, here's what actually changed, and just as importantly, what didn't.

Three RFCs instead of one

The new structure separates DMARC into three focused documents:

  • RFC 9989 — the core DMARC specification itself: policy syntax, alignment rules, and how receivers apply p= policies.
  • RFC 9990 — the format and handling of aggregate (rua) reports, the daily XML summaries most domains rely on for visibility.
  • RFC 9991 — the format and handling of failure (ruf) reports, covering per-message forensic-style reporting.

Splitting the spec this way lets each piece evolve independently — aggregate reporting can be refined without reopening the core policy syntax, for example — which is exactly the kind of change a working group makes when a decade of real-world deployment has revealed where the seams are.

What this means for your DNS record: nothing, immediately

The most important thing to know: your existing v=DMARC1 TXT record does not need to change. The tag syntax is unchanged, the policy values (none, quarantine, reject) are unchanged, and existing records remain fully valid under the new RFCs. This is a specification reorganization and clarification effort, not a breaking change to the protocol.

What's actually new

A few small but genuinely useful additions came out of the update, including refined guidance around subdomain policy testing and clearer handling for organizational domain edge cases that the original RFC 7489 left ambiguous. Domains running large, complex DNS setups — multiple subdomains, several outbound providers — are the ones most likely to notice a practical difference.

A naming note worth clearing up

"DMARCbis" is the working group's informal shorthand for this update effort — it isn't a new protocol name, and you won't see v=DMARCbis1 anywhere. The standard is still called DMARC, and it's still implemented with the same v=DMARC1 tag your DNS record already has.

Should you do anything right now?

For most domains: no immediate action needed. It's a reasonable moment to double-check that your aggregate report processor and any downstream tooling correctly handle the (unchanged) report format, and to confirm your policy is still set to where you intend it — quarantine or reject, not still sitting at none years after initial rollout. Beyond that, the update is largely a formalization of practices the ecosystem had already converged on.