DMARCbis Explained – What’s Changing and How to Prepare

DMARCbis is the long-awaited update to the original DMARC specification defined in RFC 7489. It introduces structural changes to how DMARC works, removes legacy elements, and clarifies long-standing ambiguities in domain alignment and policy handling.

While the update is not disruptive, it does change how domain boundaries are determined, how policies are applied to subdomains, and how certain tags are interpreted or removed.

This guide explains what’s changing, what stays the same, and what you should do next.

What is DMARCbis?

DMARCbis is the revised specification of Domain-based Message Authentication, Reporting, and Conformance (DMARC), developed by the IETF.

The original DMARC specification (RFC 7489) was published as an informational document.

DMARCbis is being advanced as a Proposed Standard, which signals stronger consensus and clearer implementation guidance.

The update focuses on three areas:

• Removing ambiguity in how domains are evaluated
• Simplifying the protocol by deprecating unused tags
• Giving domain owners more control over policy inheritance

Importantly, DMARCbis keeps v=DMARC1 unchanged, so existing records continue to work.

What Does DMARCbis Replace?

DMARCbis consolidates and replaces:

RFC 7489 – the original DMARC specification

RFC 9091 – the Public Suffix Domain (PSD) DMARC extension

This matters because PSD handling is now built into the core spec via the psd tag. External dependencies like the Public Suffix List are no longer required. Domain boundaries are defined directly in DNS.

What Are the Key Changes in DMARCbis?

1. DNS Tree Walk Replaces the Public Suffix List

DMARCbis replaces the Public Suffix List (PSL) with a DNS-native method called DNS Tree Walk. Instead of relying on a third-party list, it determines the organizational domain by traversing DNS directly.

How it works:

Let’s take this domain: mail.marketing.example.com

The receiver checks for a DMARC record in this order:

1. mail.marketing.example.com
2. marketing.example.com
3. example.com
4. com

At each level, it looks for a DMARC record with a psd tag:

• psd=n → this is the organizational domain → stop
• psd=y → this is a public suffix → stop
• psd=u or missing → continue upward

The search stops after a maximum of 8 levels.

This approach removes reliance on external lists, gives domain owners control over domain boundaries, and makes behavior more predictable across systems.

2. Deprecated Tags: ‘pct’, ‘rf’, ‘ri’

DMARCbis removes the following tags:

• ‘pct’ (the Percentage tag for percentage-based enforcement)
• ‘rf’ (Forensic report format)
• ‘ri’ (report interval)

These were rarely used consistently and added complexity without a clear benefit.

Note on the pct tag: Some organizations used pct to enforce DMARC policies gradually. Its removal simplifies the protocol, but also removes a phased rollout mechanism.

PowerDMARC’s view: staged enforcement is still important, but it should be handled operationally rather than through inconsistent receiver support.

3. New Tags Introduced: ‘psd’, ‘np’, ‘t’

‘psd’ (Public Suffix Domain)

The ‘psd’ tag defines domain type explicitly and controls where the DNS Tree Walk stops:

• psd=y → public suffix domain (e.g., TLD operators)
• psd=n → organizational domain
• psd=u → unknown (default behavior if omitted)

‘np’ (Non-Existent Domain Policy)

The ‘np’ tag defines the policy for non-existent subdomains and prevents the abuse of unused or unregistered subdomains.
Example: np=reject
‘t’ (Testing Mode)

The t tag signals that the domain is in testing mode.

• It does not override policy (‘p’, ‘sp’, ‘np’)
• It is advisory only
• Receivers may choose whether to honor it

Aggregate Report (RUA) Changes

DMARCbis separates aggregate reporting into a dedicated specification. While this does not break current reporting, it does signal future changes.

Key implications:

• The reporting format is being refined in a separate IETF draft
• The XML structure may evolve for better consistency
• Reporting behavior will become more standardized over time

Mailing Lists and p=reject Guidance

DMARCbis includes clearer guidance on mailing lists.

Domains whose users actively post to mailing lists are advised not to use p=reject, because this leads to legitimate emails being rejected since:

• Mailing lists often modify messages
• This breaks DKIM signatures
• SPF alignment usually fails

If your users participate in public mailing lists, avoid strict rejection policies unless you fully understand the impact.

What Stays the Same in DMARCbis?

DMARCbis is backward compatible, which essentially means that even after its official rollout, your existing DMARC record without the modern updates will still continue to function properly. Here are some things that will remain unchanged:

• Existing records using v=DMARC1 continue to work
• SPF and DKIM alignment mechanisms remain unchanged
• Core tags like ‘p’, ‘sp’, ‘rua’, and ‘ruf’ are still central

Before and After: DMARC Record Examples

Before (legacy record):

After (DMARCbis-aligned):

Learn how to publish a DMARC record.

Who Needs to Do What?

How Should I Prepare for DMARCbis?

It’s important to note that while no immediate changes are required, early alignment reduces future risk. To prepare for DMARCbis, you can use our quick checklist below:

Meet DMARCbis with PowerDMARC

PowerDMARC is fully prepared to support the transition to DMARCbis. As the specification evolves, we ensure your setup remains compliant without disruption. Here’s how we can help:

• DMARCbis-compatible record generator: Our generator already supports the new np, psd, and t tags, and flags deprecated tags like pct, rf, and ri for removal without the need for guesswork about which tags to keep or drop.
• Hosted DMARC with automatic updates: If you use our Hosted DMARC service, we update your record as the specification finalizes. When DMARCbis moves from Last Call to Proposed Standard, your configuration adapts automatically.
• Centralized visibility across all domains: Gain visibility on what’s working and what’s breaking in real time, with warnings for deprecated tags, expert recommendations, and tooltips.
• Subdomain and non-existent domain policy review: DMARCbis introduces np for non-existent subdomains. Our platform helps you audit and manage subdomains effectively to close gaps that attackers could exploit.
• Expert support to interpret and implement new changes: Our support team is available 24/7 to help you interpret the changes and plan your migration. For quick guidance on common issues, you can also use our built-in DMARC AI assistant.

Final Thoughts

DMARCbis improves clarity, simplifies implementation, and gives domain owners more control over how policies are applied. While the changes are not urgent, they are important, and organizations should take the upcoming updates into account when reviewing their authentication posture. Preparing now ensures your email authentication setup remains stable, predictable, and aligned with the next version of the standard.

The good news: you don’t have to transition to DMARCbis alone! Our team of experts is there to help you navigate industry changes and email sender requirements with ease, without the need for any technical knowledge. Contact us today to get started!

Frequently Asked Questions

Is DMARCbis published yet?

No. It is currently in IETF Last Call and expected to become a Proposed Standard.

Is DMARCbis backward compatible?

Yes, DMARCbis is backward compatible, meaning that existing DMARC records continue to function, so there is no need to rush for alignment or panic.

Do I need to update my DMARC record now?

There is currently no need to rush to update your DMARC record immediately. However, removing deprecated tags is recommended to ensure future alignment.

Does DMARCbis affect SPF or DKIM?

DMARCbis does not affect SPF or DKIM authentication as it only changes how DMARC evaluates alignment and policies.

• About
• Latest Posts

Yunes Tarada

Domain & Email Security Expert at PowerDMARC

Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.

Latest posts by Yunes Tarada (see all)

• DMARCbis Explained – What’s Changing and How to Prepare - April 16, 2026
• SOA Serial Number Format Is Invalid: Causes & How to Fix It - April 13, 2026
• How to Send Secure Email in Gmail: Step-by-Step Guide - April 7, 2026