Key Takeaways
- DMARCbis replaces the Public Suffix List with a DNS Tree Walk to identify the organizational domain using a native DNS method.
- Deprecated tags (pct, rf, ri) are removed to simplify records and eliminate inconsistent enforcement behavior.
- New tags (psd, np, t) clarify policy inheritance, define rules for non-existent subdomains, and provide a clear testing indicator.
- DMARCbis stays fully backward compatible with v=DMARC1, so existing records remain valid during transition.
- Final publication awaits completion of the failure-reporting document, but the core protocol updates are already approved.
Think of DMARCbis as DMARC 2.0. The update removes confusion, strengthens enforcement, and delivers the clarity modern email authentication needs. Because BIMI requires a fully enforced and correctly aligned DMARC policy, these improvements directly affect brand visibility in the inbox. Verifying your configuration with a BIMI checker becomes even more important as DMARCbis streamlines domain boundary detection, removes inconsistent legacy tags, and clarifies how policies inherit across subdomains. When approved, DMARCbis will obsolete RFC 7489 and 9091 and shift DMARC from an Informational standard to a fully recognized Proposed Standard, giving organizations a more stable and authoritative foundation for authentication, reporting, and brand protection.
The Biggest Changes You Need to Know
While the core mission, aligning SPF and DKIM, remains the same, DMARCbis is shaking things up under the hood.
1. Out with the Old Suffix List, In with the DNS Tree Walk
The current DMARC relies on the Public Suffix List (PSL) to figure out where your organizational domain actually ends. This list can be cumbersome and external. DMARCbis says “no thanks” and replaces it with a smarter DNS Tree Walk.
- What it does: This new method automatically traverses up your domain’s hierarchy (e.g., from mail.sales.company.com to sales.company.com and so on) looking for a valid DMARC record.
- Why it’s better: It’s a native DNS-based approach that eliminates the reliance on a third-party list, stopping the search when it finds a policy with the new psd=y (public suffix) or psd=n (organizational domain) tag. It keeps walking for a maximum of 8 levels if no tag is found.
2. Three Tags Are Getting the Axe!
To simplify the protocol and reduce headaches, DMARCbis is deprecating a few old tags that either caused confusion or were rarely used effectively:
- pct (percentage-based policy application): You won’t be able to tell receivers to only apply the policy to, say, 10% of your mail.
- rf (report format): This specified how forensic reports should be formatted.
- ri (report interval): This set the frequency for aggregate reports.
3. New Tags to Make Life Easier (and Clearer)
The streamlining is great, but DMARCbis also introduces a few new tags to add flexibility and much-needed clarity:
| New Tag | What It Does | Why It Matters |
| psd | Public Suffix Domain. Used to explicitly mark a domain as a public suffix (psd=y) or an organizational domain (psd=n). | Gives domain owners explicit control over where the DNS Tree Walk stops and how policy inheritance works. |
| t | Testing signal. An advisory tag for the receiver. | Lets the world know you’re in a testing phase, suggesting they might not want to enforce your policy yet (especially if it’s set to p=quarantine or p=reject). Note: It doesn’t change p=none. |
| np | Non-existent Policy. | Defines the DMARC policy to apply to subdomains that don’t exist (i.e., they don’t resolve), , helping you detect cases where a DMARC policy not enabled state would otherwise go unnoticed. |
4. The Docs Are Getting a Makeover!
Beyond the technical tags, the entire specification is being cleaned up. Expect better structure, clearer terminology, and more useful examples, making it much simpler for everyone to implement DMARC correctly.
Don’t Panic: What Stays the Same
Good news for your existing setup: the DMARCbis update is designed to be fully backward compatible!
- Your DMARC Version is Safe: The version tag remains v=DMARC1. Your current records will still be valid.
- Core Mechanics Remain: The fundamental alignment rules for SPF and DKIM are unchanged.
- The Policy Tags Endure: The critical policy tags (p, sp, rua, and ruf) are still the heart of DMARC functionality.
Your DMARCbis To-Do List
While there’s no fire drill, your current setup will keep working, it’s smart to future-proof your email security now.
- Do an Audit: Review your existing DMARC records and remove deprecated tags like pct or ri before they become irrelevant. Make sure your base domain has a valid policy.
- Get to Know the Tree Walk: If you have a complex subdomain structure, take the time to understand how the new DNS Tree Walk will affect policy inheritance.
- Consider the psd Tag: Familiarize yourself with how you might use psd=n or psd=y to explicitly control your domain boundaries, especially if your organization manages many brands or domains.
- Keep Your Team Informed: Make sure your security and IT teams are prepped for these changes so there are no surprises when DMARCbis officially drops.
Ultimately, DMARCbis is about giving domain owners more flexibility, clarity, and fine-grained control over their email authentication, particularly for subdomains. No need for urgent action, but starting the prep work now will ensure your email security posture is rock-solid for the next generation of DMARC.
Current Status of DMARCbis
The main specification and the aggregate reporting specification have been approved by the Internet Engineering Steering Group (IESG). This means the core protocol and the daily reporting format are finalized.
However, the final publication as an official Request for Comments (RFC) is currently pending resolution of a companion document, the failure-reporting specification (which details forensic reports).
- Main Draft Status: Approved by IESG.
- Phase: Successfully passed IETF Last Call and IESG approval.
- Blocking Issue: Final publication is delayed until the failure-reporting document is finalized and resolved.
- Expected Standard: It is on track to be published as a Proposed Standard, a higher designation than the original DMARC’s Informational status.
- Expected Publishing Date: While the original target was sometime in 2025, the timeline is now uncertain until the final reporting document is resolved.
In short, the DMARCbis content you read, the DNS Tree Walk, removal of pct/rf/ri, and addition of psd/np/t, is locked in and approved, but the official RFC number is waiting on one last piece of the reporting puzzle.
Summing Up
DMARCbis isn’t a radical overhaul, but a vital evolution to make email authentication clearer, more robust, and easier to manage, especially for complex domain structures. The main updates are centered around replacing the cumbersome Public Suffix List (PSL) with the native DNS Tree Walk to accurately find the organizational domain. This is coupled with streamlining the protocol by deprecating confusing tags (pct, rf, ri) and introducing powerful new ones (psd, np, t) to give domain owners granular control over policy inheritance and non-existent subdomains. Crucially, your existing v=DMARC1 records remain valid, making the transition a matter of proactive cleanup and optional adoption of the new features.
Frequently Asked Questions
Do I need to update my existing DMARC record immediately?
Not immediately. DMARCbis is backward compatible and still uses v=DMARC1. Existing, correctly configured records will continue to work, but you should eventually plan to remove deprecated tags like pct to clean up your record.
What is the main security benefit of the DNS Tree Walk?
It provides a more reliable and consistent way to identify the correct organizational domain for DMARC policy enforcement. This reduces reliance on external lists and significantly improves protection against sophisticated subdomain spoofing attacks.
How does the new t tag replace the old pct tag?
The t tag is a simple binary testing flag (t=y for testing/no enforcement, t=n for full enforcement). It replaces the problematic pct (percentage) tag, which was inconsistent and often led to variable enforcement across different mail receivers.
