The old situation

For over a decade, DMARC lived in RFC 7489, published back in 2015 as Informational — meaning it documented existing practice rather than being a formal Internet Standard. Every DMARC implementation since then has effectively been building against a well-written but non-binding memo.

What changed

The IETF's DMARC working group (nicknamed "DMARCbis" internally — more on that name in a second) split the spec into three separate documents, all promoted to full Standards Track:

Splitting it this way means aggregate reporting can evolve without reopening the core policy syntax — the kind of change a working group makes after ten years of real-world deployment has shown exactly where the seams are.

What you actually need to do

For most people running an existing DMARC record: nothing. v=DMARC1 is unchanged. p=none / quarantine / reject are unchanged. Your record is already compliant with the new RFCs as written.

Two things worth checking anyway:

1. If you're still at p=none years after your initial rollout — this is a fine excuse to actually check your aggregate reports and move to quarantine or reject. p=none collects data but enforces nothing.

2. If you built any tooling that parses DMARC records or reports, double check it doesn't hardcode a reference to RFC 7489 in a way that would confuse anyone reading your docs. RFC 7489 is now formally obsoleted (though still technically resolvable, just marked historic).

The naming trap

"DMARCbis" is the working group's internal nickname for this update effort. It is not a new protocol, and you will not see v=DMARCbis1 in a DNS record anywhere. If you see content using "DMARCbis" as if it's a distinct standard from DMARC — that's a sign the writer conflated the working-group nickname with the actual spec name. The standard is still called DMARC. It always was.

Why this matters beyond trivia

If you're maintaining documentation, internal wikis, or onboarding material that cites DMARC's spec — updating the RFC reference from 7489 to 9989 (plus 9990/9991 for reporting) is a small, correct thing to fix. It's also a decent signal, if you're writing publicly about this, that your content is current — a lot of existing "how DMARC works" articles online still only cite 7489 and haven't caught up.

I put together a full reference on the entire email authentication stack (SPF, DKIM, DMARC, ARC, BIMI) with real header examples throughout, if anyone wants to go deeper — Email Decoded. Happy to answer questions on DMARC, ARC, or email forensics in the comments.