DMARCbis Explained: Changes, Implications for Senders and Receivers

In May 2026, the IETF officially published DMARCbis — the new version of the DMARC (Domain-based Message Authentication, Reporting, and Conformance) standard. This update replaces RFC 7489 from 2015 with three new documents: RFC 9989, RFC 9990, and RFC 9991.

But what actually changes? Is this a revolution or an evolution? What are the concrete implications for you — whether you’re a domain administrator, email service provider, or email security specialist?

This article demystifies DMARCbis, explains its innovations, and helps you understand its impact on your infrastructure.

Context: A Long-Awaited Update

Why a New RFC?

RFC 7489 (2015) served for 11 years. During that time, several limitations and ambiguities emerged:

• Unclear policy discovery: Using an external Public Suffix List (PSL) creates implementation divergences and performance issues.
• Confusing tags: The pct= tag (sampling rate) is misused; rf= and ri= are rarely supported.
• Poor report structure: No clarity on which discovery method was used, no explicit test mode.
• Ambiguous SPF alignment: Which address to use for SPF — HELO, EHLO, or MAIL FROM?

DMARCbis addresses all these problems.

Standard Status

The move to Standards Track means future implementations must comply strictly.

The Most Important Change: DNS Tree Walk

Before (RFC 7489 + PSL)

Policy discovery used an external Public Suffix List, hosted and maintained centrally:

mail.example.com  →  Check PSL  →  Retrieve example.com policy

Problems:

• Divergence between implementations (which PSL version?)
• Dependency on a centralized operator (Mozilla maintains the public PSL)
• Inflexibility for complex domain structures

Now (RFC 9989 - DNS Tree Walk)

Discovery uses a decentralized DNS tree walking algorithm:

Domain: mail.example.com
↓
Look up _dmarc.mail.example.com → Not found
↓
Look up _dmarc.example.com → Found ✓
↓ (limit: max 8 labels, anti-DoS)

Advantages:

• ✅ Decentralized — each domain controls its own discovery
• ✅ Transparent — no external list to maintain
• ✅ Flexible — supports complex structures (*.co.uk, *.github.io, etc.)

Where Divergences Occur

Example: news.fr.example.com

Critical case: mycompany.co.uk

Recommended action: When migrating to RFC 9989, test your domain with both methods to detect any divergence.

New Tag: psd= for Public Suffix Domains

With tree walk comes a new responsibility for operators of “public” domains (.co.uk, .github.io, etc.).

v=DMARC1; p=none; psd=y; rua=mailto:dmarc@example.com

• psd=y: This is a Public Suffix Domain
• psd=n: No, it’s not a PSD (default)
• psd=u: Uncertain

Receivers then know how to handle discovery for subdomains of this PSD.

Deprecated Tags: What Disappears

These tags still exist in the DNS record but will be ignored by RFC 9989 implementations:

⚠️ Important: If your policy contains pct=50, an RFC 9989 receiver will completely ignore it and apply the policy at 100%. Don’t rely on pct= for testing anymore.

New Tags: What Arrives

t= — Explicit Test Mode

The clean replacement for the misused pct=0.

Before (RFC 7489):

v=DMARC1; p=none; pct=0; rua=mailto:...

→ Ambiguous: are you testing reject, or did you just forget to raise the policy?

Now (RFC 9989):

v=DMARC1; p=reject; t=y; rua=mailto:...

→ Explicit: “I’m testing reject, but apply quarantine or none during this test.”

RUA reports will show testing: y to confirm the active mode.

np= — Non-existent Subdomain Policy

Protects against attackers sending from random or non-existent subdomains.

v=DMARC1; p=reject; np=reject; rua=mailto:...

• np=reject: Reject emails from non-existent subdomains
• np=quarantine: Quarantine them
• np=none: No action (default)

Use case: An attacker sends from fakesupport.example.com which doesn’t exist in your DNS. With np=reject, the email is rejected.

SPF in DMARC: An Important Clarification

The Problem (RFC 7489)

Some implementations used the HELO/EHLO domain to validate SPF in DMARC. Others used MAIL FROM. Total ambiguity.

The Rule (RFC 9989)

SPF domain scope = MAIL FROM only. No HELO fallback.

Example:

MAIL FROM: <sender@subdomain.example.com>
HELO: smtp.cloudflare.com
From: user@example.com

For DMARC, SPF must validate subdomain.example.com (MAIL FROM), not smtp.cloudflare.com (HELO).

RUA Report Format (RFC 9990)

New Fields in Reports

Aggregate reports now include two key fields absent from RFC 7489:

<policy_published>
  <discovery_method>treewalk</discovery_method>   <!-- treewalk or psl -->
  <testing>y</testing>                            <!-- y if t=y active -->
  <np>none</np>                                   <!-- np= policy applied -->
</policy_published>

What These Fields Tell You

Implications for Senders

What Stays the Same

• ✅ Your existing policies continue to work
• ✅ Tags v, p, sp, rua, ruf are unchanged
• ✅ No urgent action required

What Needs Attention

• ⚠️ pct= will be ignored by RFC 9989 receivers → migrate to t=y
• ⚠️ Test PSL vs tree walk divergences if your domain has a complex structure
• ⚠️ Verify your SPF validates MAIL FROM (not HELO)

Recommended Migration Path

Implications for Mailbox Providers (Receivers)

Increased Complexity

Tree walk implementation is more complex than consulting a PSL:

• Additional DNS queries per email
• Tree traversal algorithm to manage
• Dual support PSL + tree walk during transition

Estimated Deployment Timeline

The transition will take 2 to 3 years. Supporting both methods is mandatory during this period.

Backward Compatibility: The Summary

Backward compatibility level: Moderate ⚠️

Recommendations

1. Test your domain with PSL and tree walk — check for divergence
2. Replace pct= with t=y; p=reject now
3. Monitor discovery_method in your RUA reports
4. Your report provider should support both methods until 2028

Summary: RFC 7489 vs RFC 9989

Official Resources

• RFC 9989 — DMARC Specification (Protocol core)
• RFC 9990 — DMARC Aggregate Reporting
• RFC 9991 — DMARC Failure Reporting
• dmarc.org — Community resources
• IETF DMARC WG — IETF Working Group

DMARCbis is a major evolution, not a revolution for most domain administrators. Your existing policies remain valid, but leveraging the new features (test mode, np=, tree walk) will give you better protection and more flexibility.

Next step: Read our DMARCbis Practical Guide for concrete actions to take on your domain.