If you've ever pasted v=DMARC1; p=reject; into a TXT record and moved on with your life, here's something worth two minutes: the spec behind that record just changed. Not the syntax — the actual standard.
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:
| RFC | Covers |
|---|---|
| RFC 9989 | Core DMARC spec — policy syntax, alignment rules, how receivers apply p=
|
| RFC 9990 | Aggregate (rua) report format and handling |
| RFC 9991 | Failure (ruf) report format and handling |
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:
-
If you're still at
p=noneyears after your initial rollout — this is a fine excuse to actually check your aggregate reports and move toquarantineorreject.p=nonecollects data but enforces nothing. - 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.
Top comments (1)
Good rundown, and "your record doesn't need to change" holds for the syntax — but there's a receiver-side change in the same update worth flagging for anyone running a lot of subdomains. DMARCbis drops the Public Suffix List for figuring out the organizational domain and replaces it with a DNS tree walk: receivers now climb the DNS hierarchy looking for a DMARC record instead of consulting the PSL. For a bare apex that's invisible, but if you were relying on a subdomain inheriting the org-domain policy, the discovery path that decides whether your sp= applies just changed underneath you — so it's worth setting sp= explicitly rather than trusting inheritance.
Two smaller ones from the same work: the pct= tag is gone, so any gradual-rollout tooling still emitting pct=50 is now effectively a no-op, and there's a new np= tag for non-existent subdomains that's worth setting to reject. That one closes a gap a plain apex policy doesn't — the lookalike subdomain (invoices.yourbrand.com that was never provisioned) that attackers spin up precisely because nothing was published there.