DMARC grew up.Meet DMARCbis.
After eleven years, the IETF replaced the original DMARC spec. RFC 9989, 9990 and 9991 make DMARC a real internet standard — and quietly rewrite a few things in your record. Here's what changed, and what it deliberately left alone.
DMARC moved from Informational — a published idea — to a Proposed Standard the internet formally agrees on. The protocol that protects your domain is no longer a de facto convention. It's the rulebook.
One spec became three RFCs.
"DMARCbis" is the multi-year effort to revise DMARC. On 2026-05-20 it landed as three documents that together obsolete RFC 7489 from 2015. Splitting one specification into three lets each part evolve without re-opening the others.
RFC 9989
Core protocol
How records are published, evaluated and aligned — the heart of DMARC.
RFC 9990
Aggregate reporting
The daily XML summaries you already receive from mailbox providers.
RFC 9991
Failure reporting
Per-message forensic reports for individual authentication failures.
After a decade as the convention everyone followed, DMARC is finally the standard everyone agreed to.
What changed in your record.
Six changes touch the DMARC record itself. None of them break a v=DMARC1 record you already publish — but a few are worth a cleanup pass.
pct= → t=
RemovedPercentage rollout is gone
The pct= tag is removed. In its place a binary t= flag marks a policy as testing (t=y) or live. A policy is now either enforced or it isn't — no partial percentages.
Tree Walk
ChangedNo more Public Suffix List
Organizational-domain discovery no longer relies on publicsuffix.org. Receivers walk up the DNS tree (up to eight queries) to find the governing _dmarc record.
np=
NewNon-existent subdomain policy
A new np= tag sets policy for subdomains that don't exist at all — a favourite of spoofers. np=reject refuses invented subdomains while the rest of the domain keeps a softer policy.
psd=
NewPublic suffix operators, folded in
The psd= tag from RFC 9091 is now part of the core spec, formally supporting public-suffix operators such as .bank and .gov.
SPF
ChangedMAIL FROM only
DMARC's SPF check now aligns on the MAIL FROM domain only — the HELO fallback is gone. A handful of senders that leaned on HELO alignment may need DKIM to carry the pass.
rf= ri=
RemovedReporting tags deprecated
The report-format (rf=) and report-interval (ri=) tags are deprecated. They were near-universally ignored in practice; you can safely drop them from your record.
What it doesn't change.
This is the part the launch coverage tends to skip. DMARCbis is a syntax and standards update — not a security upgrade.
A domain sitting at p=none is exactly as spoofable under RFC 9989 as it was under RFC 7489. The three policy levels — none, quarantine, reject — mean precisely what they always did. Nothing in DMARCbis moves a single domain from monitoring to protection.
So the work that actually stops impersonation is untouched: inventory every legitimate sender, get SPF and DKIM aligned, and advance the policy to p=reject without breaking real mail. The standard got cleaner. The last mile got no shorter.
The spec now names the gap.
There's a quiet irony in the new t= flag. By replacing the fuzzy pct= percentage with a clean binary — t=y for testing, nothing for live — DMARCbis writes the distinction we've been making all along directly into the protocol.
A policy is now either being tested or being enforced. There is no longer a comfortable middle where a domain feels protected at 10%. The spec itself now draws the line between watching spoofing happen and actually stopping it.
That line is the whole game. Monitoring vs enforcement — the full breakdown.
What to do now.
There's no scramble. Four steps, ordered from least effort to most.
01
Leave v=DMARC1 alone
Your record still validates. There is no flag day and no forced migration.
02
Tidy the deprecated tags
Remove pct=, rf= and ri=. They no longer do anything; dropping them keeps the record clean.
03
Consider np=reject
If you don't send from made-up subdomains — almost nobody does — closing them off is free protection.
04
Then do the real work
If you're at p=none, the most valuable thing DMARCbis can prompt you to do is the thing it didn't change: get to enforcement.
Authex already speaks DMARCbis.
Because Authex owns your trust records, the syntax housekeeping is automatic — clean records, the right tags, np= where it helps. But the reason Authex exists is the part DMARCbis left unsolved: it runs the last mile to p=reject for you, deterministically, gated by your real report data — and holds it there against drift.
Questions, answered.
Do I need to update my DMARC record for DMARCbis?
For most domains, no. Records still start with v=DMARC1 and existing RFC 7489 records remain valid — nothing breaks on its own, and there is no flag day. The housekeeping is small: drop the deprecated pct=, rf= and ri= tags, and consider adding np= for non-existent subdomains. The substantive work — moving from p=none to enforcement — is unchanged.
Is the pct= tag still supported in DMARCbis?
No. pct= is removed. It is replaced by a binary t= flag: t=y marks a policy as testing, so receivers treat enforcement as provisional, and its absence means the policy is live. Partial percentage rollouts are gone — a policy is either being tested or enforced.
What is the DMARC Tree Walk?
It is the new way DMARCbis discovers your organizational domain. Instead of consulting the Public Suffix List (publicsuffix.org), a receiver walks up the DNS tree from the sending domain — up to eight queries — until it finds a _dmarc record. This removes DMARC's dependency on an externally maintained list.
Does DMARCbis make my domain more secure automatically?
No. DMARCbis modernizes the syntax and promotes DMARC to a Proposed Standard, but a domain at p=none is exactly as spoofable as it was before. Protection still begins only when you move to p=quarantine or p=reject. The standard didn't change that — it just gave the protocol a formal home.
What is the np= tag?
np= sets the policy for non-existent subdomains — names with no DNS records at all, which are a common spoofing target. You can publish np=reject to refuse mail from invented subdomains while keeping a softer policy on the rest of your domain.
Is there a DMARCbis deadline I need to meet?
No. DMARCbis has no flag day. RFC 7489 records stay valid and receivers are adopting the new rules transparently. The practical priority is the same as it was the day before publication: get from p=none to enforcement.
New standard. Same unprotected domains.
Scan free to see whether yours is actually enforcing — then let the Agent take it the rest of the way.
Free · No signup