DMARCbis Is Official: What It Is, Key Changes in RFC 9989, 9990, and 9991, and How to Prepare

TL;DR

• DMARCbis is now official: After years of work by the IETF working group, the DMARC specification has been formally updated. Three new documents, RFC 9989, RFC 9990, and RFC 9991, replace the informational RFC 7489 from 2015.
• Backward compatibility: Existing records starting with v=DMARC1 remain fully valid. No mass configuration updates required.
• DNS Tree Walk algorithm: The static Public Suffix List (PSL) has been replaced by the dynamic DNS Tree Walk algorithm, which determines the Organizational Domain more accurately and reliably.
• A new approach to p=reject: The new specification explicitly discourages strict message rejection for indirect mail flows. Receiving servers are now mandated to treat such messages as p=quarantine in the absence of additional context.

What Is DMARC and Why Does It Matter?

Before diving into what DMARCbis actually changes, it’s worth covering the basics of what DMARC does and why it matters.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM authentication to the domain visible in the “From” header, giving receiving servers clear instructions on how to handle messages that fail verification. It also generates reports that let senders see exactly who is sending email from their domain, including any unauthorized spoofing attempts.

Domain owners can enforce one of three policies:

• none: the receiving server takes no action on failing messages but generates and sends reports to the sender.
• quarantine: messages that fail verification are routed to the spam folder.
• reject: failing messages are blocked entirely before reaching the recipient’s inbox.

In early 2024, Google and Yahoo mandated DMARC implementation for bulk senders, effectively making it a baseline requirement rather than a best practice.

Marketer callout: Even if you’re not managing DNS records yourself, understanding these three policies helps you grasp the business implications of your authentication setup and know the right questions to ask your tech team when deliverability issues arise.

From RFC 7489 to DMARCbis: A Decade in the Making

The original DMARC specification, documented in RFC 7489, was published in 2015 as an informational document rather than a formal internet standard. While the protocol became widely adopted, its implementation remained inconsistent – mailbox providers could interpret the spec in their own ways, and often did.

After years of work by the IETF (Internet Engineering Task Force) working group, the protocol underwent a comprehensive revision. The process took this long partly because the spec needed to address complex challenges that RFC 7489 hadn’t anticipated: indirect mail flows, Public Suffix Domain handling, and the growing complexity of the email ecosystem.

The updated specification, known as DMARCbis, is split into three dedicated documents:

• RFC 9989: the primary document covering the core DMARC mechanism.
• RFC 9990: the specification governing aggregate reports.
• RFC 9991: the specification governing failure reports.

Todd Herr, one of the editors of RFC 9989, confirmed the publication on LinkedIn, noting its significance for the broader email ecosystem. The full document is available via the RFC Editor.

With these publications, DMARC has officially achieved IETF Proposed Standard status. In practice, this means mailbox providers worldwide will interpret and implement the protocol more consistently. It also brings clearer definitions, better examples, and more actionable guidance for administrators – all immediately visible in how much more readable these documents are compared to RFC 7489.

No, This Is Not DMARC2: What Backward Compatibility Actually Means

Despite how comprehensive this update is, DMARCbis introduces no breaking changes. The concept of “DMARC2” simply does not exist, and that is by design: the new tags and revised rules are built so that servers running the legacy standard can safely ignore them without any errors.

All DMARC records must still start with v=DMARC1. That is good news for anyone managing email infrastructure. Existing, correctly configured records remain fully functional, and email administrators do not need to rush through mass DNS updates. The right time to plan strategic record updates is once major mailbox providers have fully implemented and validated the new specification on their end.

What Actually Changed: Key Technical Updates

DMARCbis introduces several significant technical changes, each worth looking at separately. They cover the policy record structure, how the organizational domain is determined, and new conformance requirements.

Tag Changes: The Short Version

The DMARC policy record structure has been updated. Some existing tags were deprecated due to low adoption or redundancy. At the same time, new parameters were added to meet the current demands of the email ecosystem.

Deprecated Tag	New Tag	Technical Function
pct	t	The percentage parameter has been removed and replaced by the t (testing) tag, which allows policy testing without global enforcement.
rf	None	The reporting format parameter has been deprecated, as standard XML formats are now universally expected.
ri	None	The reporting interval parameter has been removed entirely.
None	np	Allows defining a DMARC policy specifically for non-existent subdomains.
None	psd	Used to declare a domain as a Public Suffix Domain.

Marketer callout: If your tech team is using the pct tag (e.g., pct=50 for a gradual policy rollout), it’s worth planning a migration to the new t tag. The functionality is similar, but the new syntax is simpler and more predictable.

DNS Tree Walk Replaces the Public Suffix List

Until now, DMARC relied on the Public Suffix List (PSL) to determine the organizational domain for record discovery and identifier alignment. Relying on the PSL came with real operational drawbacks: it required manual updates, caused propagation delays, and introduced errors in complex domain structures.

RFC 9989 replaces the PSL with the DNS Tree Walk algorithm. Instead of querying a static external database, the system dynamically traverses the DNS hierarchy level by level until it precisely identifies the organizational domain boundary. This delivers significantly better support for Public Suffix Domain (PSD) environments and enables their full participation in the DMARC ecosystem.

Conformance Requirements

The updated specification introduces a new section dedicated to what full DMARC participation actually requires. It establishes precise technical criteria for both domain owners and receiving servers. Turning informal best practices into formal requirements will help drive greater consistency across the global email infrastructure.

The p=reject Controversy: What RFC 9989 Actually Says

The most consequential change in DMARCbis concerns the approach to p=reject. Indirect mail flows, including forwarding and mailing lists, have been breaking DMARC identifier alignment for years. That technical limitation remains unresolved in the new specification too.

RFC 9989 addresses this head-on, explicitly discouraging the immediate rejection of messages transmitted via indirect routes. The spec puts a clear requirement on receiving servers:

“In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were ‘p=quarantine’ rather than ‘p=reject’.” (RFC 9989, Section 7.4)

In RFC terminology, MUST is a hard requirement, not a suggestion. Receiving servers cannot reject messages solely on the basis of a p=reject tag if the verification failure stems from forwarding or other indirect flows.

The practical implications are real. Domain owners should hold off on enforcing p=reject if their recipients use mailing lists or forwarding. The spec recommends monitoring aggregate reports for alignment failures first and only escalating policy once those issues are cleaned up.

Marketer callout: If you send newsletters through external platforms or your messages reach recipients via discussion lists, p=reject can silently block legitimate email. Before enforcing it, review your DMARC reports for indirect flows and loop in your tech team. It’s worth doing before you flip that switch, not after.

Reporting Updates: RFC 9990 and RFC 9991

• Aggregate reports (RFC 9990): The rules for generating aggregate reports have been tightened, with stricter requirements for report senders. The XML format has also been updated to incorporate the new record tags and to reflect how mailbox providers actually operate today, rather than the theoretical model from RFC 7489.
• Failure reports (RFC 9991): The failure reporting mechanism received only minor technical updates. A new section was added, however, addressing the privacy implications of sharing per-message diagnostic data.

Marketer callout: Once mailbox providers roll out the new spec, it’s worth keeping a closer eye on your aggregate report data. Watch for unexpected shifts in bounce rates or sudden changes in identifier alignment. Either could be a signal that something needs attention on the technical side.

How to Prepare for DMARCbis: A Practical Checklist for Technical Teams and Marketers

DMARCbis doesn’t require immediate action, but it’s a good opportunity to audit your configuration and rethink your authentication strategy. Here’s what to focus on depending on your role.

Recommendations for Email Administrators and Technical Teams

• Audit existing records: review your current DMARC configuration, particularly for deprecated tags pct, rf, and ri. Their presence won’t cause errors right now, but it’s worth knowing which records will eventually need attention.
• Plan tag migrations: prepare for the transition from pct to the new t tag and the removal of obsolete parameters. No need to act immediately, but it’s worth adding to your backlog.
• Monitor reports systematically: before moving to p=reject, analyze aggregate reports for alignment failures in indirect flows. Escalating policy without this groundwork is a reliable way to accidentally block legitimate email.
• Avoid rushed changes: hold off on significant DNS modifications until leading mailbox providers confirm full DMARCbis implementation on their end.

Recommendations for Marketers and Domain Owners

• Check that aggregate reporting is enabled: if your DMARC record doesn’t include the rua tag, you’re not collecting any data on how your messages are being authenticated at the recipient end. Without it, you’re flying blind on deliverability.
• Coordinate with your tech team before switching ESPs: changing your sending platform or adding a new marketing tool can disrupt identifier alignment. Verify the configuration before the migration, not after.
• Think about how your audience receives email: enforcing p=reject can block messages for subscribers using mailing lists or forwarding. In those cases, p=quarantine combined with active monitoring is the safer choice.

DMARCbis in the Bigger Picture

The publication of RFC 9989, 9990, and 9991 is not an isolated event. It is the next phase in a deliberate, multi-year push by the email industry toward universal and enforceable authentication.

Things are moving quickly. The sender requirements introduced by Google and Yahoo in early 2024 pushed senders who had been dragging their feet on DMARC to finally act. DMARCbis formalizes and standardizes what has effectively become the market baseline.

Meanwhile, DKIM2 is in active development, designed to solve the indirect flow problem at its source rather than working around it. ARC, the protocol built as a temporary fix for that same problem, has already been formally proposed for deprecation.

Taken together, these developments point in one clear direction: stronger, more predictable, and harder-to-abuse email authentication at every stage of delivery. For high-volume senders, the takeaway is straightforward. Stay close to these changes, because the next steps will come fast.