DMARCbis Is Official: RFC 9989, 9990, and 9991 Replace RFC 7489

The next evolution of DMARC has officially arrived. After years of discussion and development within the IETF (Internet Engineering Task Force), the updated DMARC specifications — commonly referred to as DMARCbis — have now been published as official RFCs.

At the same time, platforms such as DMARCReport already support DMARCbis record creation and DMARCbis-compatible record processing, helping organizations prepare for the latest standard without needing to manually decode every specification change.

The original Reddit announcement discussing the publication of the RFCs can be found here:

Original Reddit Discussion on r/DMARC

The newly published RFCs are:

• RFC 9989 – Main DMARC Specification
• RFC 9990 – Aggregate Reporting
• RFC 9991 – Failure Reporting

These documents officially replace the original DMARC RFC 7489, which had been in place since 2015.

What Is DMARCbis?

DMARCbis is the modernized revision of the original DMARC specification. Rather than introducing an entirely new protocol, it refines and reorganizes the existing DMARC framework to better reflect real-world email authentication practices.

Importantly, this is not “DMARC2.”

Existing DMARC records remain valid, and the protocol identifier still uses:

v=DMARC1

This means organizations do not need to overhaul their deployments overnight. Instead, DMARCbis introduces a cleaner, more flexible, and more standards-driven approach to authentication, reporting, and policy evaluation.

The updated RFCs also elevate DMARC to an official IETF Proposed Standard, giving it stronger standardization status within the internet ecosystem.

Why the DMARC Specification Needed an Update

The original RFC 7489 played a major role in improving email authentication and reducing spoofing attacks across the internet. However, over nearly a decade of deployment, several operational challenges became apparent.

Some of the biggest issues included:

• Complicated language and ambiguous interpretations
• Inconsistent handling by mailbox providers
• Problems involving mailing lists and forwarded email
• Limited support for Public Suffix Domains (PSDs)
• Reporting inconsistencies between implementations
• Unclear guidance around full DMARC participation

DMARCbis aims to address many of these gaps while keeping backward compatibility intact.

Major Changes Introduced in RFC 9989

1. A Completely Restructured Specification

One of the biggest improvements is readability.

The new RFC reorganizes the DMARC specification into a more logical structure with:

• Better examples
• Clearer terminology
• More implementation guidance
• Improved explanations for edge cases
• Better alignment with modern deployment practices

This makes the protocol easier for:

• Security teams
• DNS administrators
• Email providers
• SaaS vendors
• Compliance teams
• Developers building DMARC tooling

The updated documentation also reduces ambiguity that previously led to inconsistent implementations.

2. New “Full DMARC Participation” Requirements

A significant addition is the new section defining:

“Conformance requirements for full DMARC participation”

This section helps organizations and mailbox providers determine whether they are correctly implementing DMARC best practices.

The guidance clarifies expectations around:

• Policy evaluation
• Alignment behavior
• Record processing
• Reporting compliance
• Receiver-side implementation
• Sender-side deployment expectations

This is particularly important because many providers historically implemented only partial DMARC functionality, leading to inconsistent enforcement across the ecosystem.

3. Changes to DMARC Record Tags

DMARCbis updates the supported tags within DMARC DNS records.

Removed Tags

The following tags were removed:

• pct
• rf
• ri

These tags were either underused, inconsistently implemented, or no longer aligned with current practices.

New Tags Added

The following tags were introduced:

• np
• psd
• t

These additions improve flexibility and enable better handling of newer DMARC deployment models, especially for Public Suffix Domains.

Even with these changes, the protocol remains backward compatible.

A modern DMARC record still starts with:

v=DMARC1;

4. Public Suffix List Replaced With DNS Tree Walk

This is one of the most technically important changes in DMARCbis.

Previously, DMARC relied heavily on the Public Suffix List (PSL) to determine the Organizational Domain during:

• DMARC record discovery
• Identifier alignment checks

Under DMARCbis, the PSL mechanism has been replaced by a more flexible DNS Tree Walk algorithm.

Why This Matters

The Public Suffix List worked reasonably well but had limitations:

• It depended on external maintenance
• It lacked flexibility
• Certain domain structures were difficult to support
• Public Suffix Domains had limited participation capabilities

The new DNS Tree Walk approach allows for:

• Better scalability
• More accurate organizational domain discovery
• Improved support for PSD operators
• Greater flexibility across complex domain structures

This is one of the foundational architectural changes introduced by RFC 9989.

5. Better Support for Public Suffix Domains (PSDs)

DMARCbis significantly improves support for Public Suffix Domains.

Examples of PSDs include:

• .bank
• .gov
• .edu
• Country-level domain structures in some regions

Historically, PSDs could not fully participate in DMARC enforcement because of limitations in how organizational domains were discovered. The new specifications improve PSD support through:

• DNS Tree Walk processing
• New policy behaviors
• Additional DMARC record tags
• Better alignment rules

This allows PSD operators to play a larger role in protecting entire domain ecosystems.

6. Mailing Lists and Forwarding Still Remain a Problem

One major issue remains unresolved:

Indirect Email Flows

Forwarding services and mailing lists can still break DMARC alignment.

This happens because forwarded messages often modify:

• Return-Path values
• DKIM signatures
• Message headers

As a result, legitimate forwarded mail may fail DMARC checks.

The updated RFC acknowledges this ongoing challenge and now discourages aggressive reject policies in environments where mailing lists are common.

This is a notable shift because the specification now more openly recognizes the operational realities of email delivery.

Updates to Aggregate Reporting (RFC 9990)

Aggregate reporting received important improvements as part of RFC 9990.

The XML report format has been modernized to:

• Support new DMARCbis tags
• Improve validation consistency
• Reflect real-world deployment practices
• Standardize reporting behavior
• Reduce ambiguity across implementations

These changes should improve interoperability between:

• Mailbox providers
• DMARC monitoring platforms
• Enterprise security tools
• Reporting parsers

Organizations processing DMARC XML reports should ensure their tooling supports RFC 9990 compatibility.

Platforms like DMARCReport already process DMARCbis-compatible aggregate reports and updated record formats.

Updates to Failure Reporting (RFC 9991)

Failure reporting saw fewer changes compared to aggregate reporting, but there are still meaningful updates.

RFC 9991 introduces:

• Better clarification around report handling
• Improved consistency language
• Additional privacy considerations
• Updated terminology
• Minor modernization of reporting behaviors

The specification also more clearly acknowledges the privacy implications of forensic/failure reporting, which has long been a concern within the email security community.

Is This a Breaking Change?

No.

DMARCbis was intentionally designed to avoid breaking existing deployments.

Organizations using DMARC today generally do not need to:

• Replace all records
• Change the protocol version
• Rebuild enforcement policies
• Redesign reporting workflows

However, administrators should review their deployments to ensure compatibility with the updated standards and newer record processing behaviors.

What Organizations Should Do Next

Review Existing DMARC Records

Check whether your current records rely on deprecated tags or outdated assumptions.

Update Internal Documentation

Security teams and email administrators should familiarize themselves with:

• RFC 9989
• RFC 9990
• RFC 9991

Especially the updated alignment and organizational domain logic.

Ensure Your DMARC Platform Supports DMARCbis

Not all tools currently support the new standards fully.

Solutions such as DMARCReport already support:

• DMARCbis record creation
• Updated record parsing
• RFC 9990 aggregate report handling
• Modern DMARC processing behavior

Monitor Mailing List and Forwarding Issues

Organizations using strict enforcement policies should continue carefully monitoring:

• Mailing list traffic
• Third-party forwarding services
• Legacy email relays
• External collaboration platforms

These remain common sources of authentication failure.

The Bigger Picture

DMARCbis represents one of the most important updates to email authentication standards in years.

Rather than reinventing DMARC, the new RFCs modernize it for the realities of today’s internet:

• More complex domain ecosystems
• Better standardization
• Improved interoperability
• Stronger guidance
• Modern reporting behavior
• Expanded PSD participation The publication of RFC 9989, 9990, and 9991 signals that DMARC is no longer just an industry best practice — it is now a more mature and formally standardized component of global email security infrastructure.

For organizations serious about protecting their domains from spoofing, phishing, and impersonation attacks, understanding DMARCbis is now essential.