DMARCbis is finishing its journey through the IETF, replacing RFC 7489 with a Standards Track spec. The tree walk, retired tags, and what senders should do now.
The DMARC every mail system implements today is RFC 7489, published in 2015 as an Informational document: a description of an industry practice rather than an internet standard. Ten years and one mandatory-authentication era later, the IETF's DMARC working group has finished its rewrite. DMARCbis has cleared working group last call and IETF review, and sits in the publication queue to replace RFC 7489 as a Proposed Standard. Here is what actually changes, and the honest answer for most senders is: less than the headlines suggest, with two exceptions worth acting on.
From the PSL to the tree walk
The largest technical change is invisible to most record owners. RFC 7489 finds the organizational domain, the domain whose policy governs subdomains and whose boundary defines alignment, using the Public Suffix List, a volunteer-maintained text file of registry boundaries. The PSL was always an awkward dependency: unversioned, informally governed, and never designed to carry authentication semantics.
DMARCbis replaces it with a DNS tree walk. A receiver evaluating mail.eu.example.com queries for DMARC records up the name hierarchy, and tags in the discovered records (psd=y among them) mark where the organizational boundary sits. The authority moves from an external file into DNS itself, where domain owners can express their own structure. Receivers do the walking; senders mostly notice nothing, unless their domain architecture sits near a boundary the PSL and the tree walk judge differently, which is rare and mostly affects public suffix operators and deeply nested multinational domain trees.
1. _dmarc.mail.eu.example.com -> no record
2. _dmarc.example.com -> longest remaining candidate checked
(walk queries selected labels between leaf and root, max 5 lookups)
3. Record found at example.com -> organizational domain, policy applies
psd=y in a record marks a public suffix boundaryTags retired and tags added
The pct tag is gone. Percentage-based rollout sounded sensible and never worked as advertised: receivers implemented it inconsistently, and applying quarantine to a random 30% of failing mail produced noise rather than a gradual rollout. Its removal formalizes what practitioners already knew, and the p=none, then quarantine, then reject ladder with aggregate report monitoring, exactly the process our DMARC series documented, is the supported rollout path.
The np tag is new: a policy specifically for non-existent subdomains, ones with no resolvable records at all. This closes a real abuse hole, spoofing invented subdomains like invoices.example.com that the owner never created, without forcing the stricter policy onto legitimate subdomains still in rollout. A record can now say p=quarantine sp=quarantine np=reject: cautious on real infrastructure, merciless on fabricated names. In addition, several little-used features (ri for report interval negotiation, the afrf format tag, ruf in practice) are trimmed or de-emphasized, matching what receivers actually implemented.
Standards status matters more than it sounds
Graduating from Informational to Standards Track is bureaucratic on the surface and consequential underneath. Regulators, procurement frameworks, and compliance regimes cite standards; an Informational RFC always carried an asterisk. With NIS2 auditors reading state of the art into email controls and every major mailbox provider mandating DMARC, a Proposed Standard closes the loop: the thing everyone requires is now formally a standard. Expect security questionnaires and government guidance to reference the new RFC quickly, and expect DMARC absence to look progressively less defensible in any audit.
The reporting side is also being split into companion documents, aggregate reporting and failure reporting as their own specs. The XML you parse does not meaningfully change, and parsedmarc pipelines built on our aggregate reports guide continue working untouched.
What to actually do
DMARCbis readiness, in order of urgency
- 1
Remove pct from your records
If a record still carries pct=, the rollout it was managing is either finished or stalled. Finish it properly with monitoring, and delete the tag.
- 2
Audit subdomain policy coverage
Review sp= on your organizational domain and plan where np= fits once receiver support lands. Non-existent-subdomain spoofing is the hole it closes.
- 3
Check unusual domain structures
If you operate under a private registry-like suffix or a deeply delegated tree, verify the tree walk finds the record you intend to govern. Standard corporate domains can skip this.
- 4
Keep the monitoring loop running
Nothing in DMARCbis changes the operational core: aggregate reports in, source triage, enforcement policy maintained. The process articles in this series apply unchanged.
DMARCbis is consolidation, not revolution: the standard catching up to a decade of deployment experience and shedding the parts that never worked. The senders with clean, enforced, monitored DMARC today will not notice the transition, which is precisely the position to be in when the RFC number lands and the compliance frameworks start citing it.
Frequently Asked Questions
Do I need to change v=DMARC1 to something new?
When do receivers switch to the tree walk?
Does DMARCbis fix the mailing list problem?
Should I wait for DMARCbis before deploying DMARC?
Key Takeaways
- DMARCbis replaces RFC 7489 as a Proposed Standard, upgrading DMARC from Informational status after a decade
- Policy discovery moves from the Public Suffix List to a DNS tree walk, with psd= marking boundaries
- The pct tag is retired; the np tag adds a policy for non-existent subdomains worth adopting
- Existing v=DMARC1 records remain valid; backward compatibility was a design requirement
- Action items: drop pct, plan np coverage, verify unusual domain trees, and keep the monitoring loop unchanged
Related articles
2025 in Email: The Year Authentication Became Mandatory Everywhere
Microsoft joined the mandate, Gmail moved to hard rejection, and DMARCbis reached the finish line. What 2025 changed for senders and what it sets up for 2026.
Greylisting, Tarpitting, and Other Receiver Defenses Senders Should Understand
Receiving servers defend themselves with deliberate delays, temporary rejections, and traps for impatient senders. How each defense works and how a good MTA passes them.
Building a Deliverability Monitoring Stack
Postmaster Tools, SNDS, FBLs, DMARC reports, TLS-RPT, bounce logs, engagement data: the full observability stack, what each layer catches, and the alerts worth paging on.