Latest RFC 9989 Updates: DMARC Is Now a Proposed Standard
DMARC continues to progress as email providers and standards organizations work to make email authentication more reliable, secure, and easier to implement.
In May 2026, the Internet Engineering Task Force (IETF) published a major update to the DMARC specification. During development, these changes were commonly known as DMARCbis, the long-awaited revision of the original DMARC standard. Now that the work is complete, the term “DMARCbis” no longer exists as a working project. It has officially become the new DMARC specification through RFC 9989, RFC 9990, and RFC 9991.
The latest DMARC specification, defined in RFC 9989, introduces several important updates that affect how DMARC policies are discovered, how organizational domains are determined, and how DMARC records are configured.
While most senders don't need to make immediate changes, being aware of these updates can help you maintain a compliant authentication setup. In this article, we'll break down the most important changes and explain what they mean for domain owners and email senders.
Key Takeaways
- RFC 9989, RFC 9990, and RFC 9991 officially replace RFC 7489, published in 2015, and form the new DMARC specification.
- The long-running DMARCbis project has officially become the new DMARC specification
- DMARC has moved from Informational status to a Proposed Standard on the IETF Standards Track.
- DMARC policy discovery now uses DNS Tree Walk instead of relying on the Public Suffix List (PSL).
- New DMARC tags have been introduced, including np, psd, and t.
- Legacy tags such as pct, rf, and ri have been retired.
- Existing DMARC records continue to work, but some record optimizations are recommended.
- Monitoring DMARC reports remains essential for identifying authentication issues and maintaining compliance.
- Checking your DMARC tool for compatibility with the latest updates is useful for ensuring that your authentication setup and report processing work reliably.
What Is RFC 9989?
RFC 9989 is the latest official specification for the DMARC protocol. It defines how domain owners publish DMARC policies, how receiving mail servers evaluate messages, and what actions should be taken when authentication checks fail.
The new RFC replaces RFC 7489 and RFC 9091 and introduces several refinements designed to improve consistency, reduce ambiguity, and simplify DMARC processing across email ecosystems.
DMARC Becomes a Proposed Standard
One of the most significant changes is that the new RFC specification moved DMARC from Informational status to a Proposed Standard on the IETF Standards Track.
This reflects how widely it has been adopted by mailbox providers, businesses, and security teams, and also provides clearer implementation guidance for both senders and receivers.
These changes represent a positive step for email and the internet. A more secure digital environment benefits everyone, and the timely implementation of appropriate enforcement early can help prevent potential problems.
Updated DMARC Policy Discovery and Organizational Domain Detection
One of the most significant changes affects how email receivers locate DMARC policies.
Previously, DMARC relied on the Public Suffix List (PSL) to determine an organization's domain boundary. RFC 9989 replaces this approach with a method known as DNS Tree Walk.
What Is DNS Tree Walk?
DNS Tree Walk is a step-by-step DNS lookup process used to locate DMARC policies within a domain hierarchy.
When evaluating a message, a receiving server:
Step 1. Checks for a DMARC record on the exact sending domain (e.g., _dmarc.email.marketing.example.com).
Step 2. If no record exists, it moves up one level in the domain hierarchy (e.g., _dmarc.marketing.example.com).
Step 3. Continues checking parent domains until a valid DMARC policy is found or a predefined lookup limit is reached (e.g., the process stops after 8 queries to prevent amplification attacks).
This new approach reduces dependence on external Public Suffix Lists and provides a more standardized method for determining policy boundaries.
For most senders, no action is required, but DMARC monitoring platforms and email providers must adapt their processing logic accordingly.
DMARC Report Size Parameter Removed
RFC 9989 removes support for specifying a maximum aggregate report size within DMARC reporting URIs.
Previously, administrators could use syntax such as: “rua=mailto
This functionality is no longer part of the standard and should not be relied upon moving forward.
New DMARC Record Tags
The update introduces several new tags:
- np: Policy for Non-Existent Subdomains
The “np” tag allows domain owners to define a policy specifically for messages claiming to come from subdomains that do not actually exist (example: “np=reject”).
This provides an additional layer of protection against spoofing attempts targeting unused subdomains. - psd: Public Suffix Domain Indicator
The “psd” tag identifies whether a domain operates as a Public Suffix Domain.
This tag is mainly relevant to registry operators and specialized domain infrastructures. - t: Testing Flag
The new “t” tag replaces the former “pct” percentage-based rollout mechanism.
Available values:
“t=n” — Default behavior. The DMARC policy is applied as published (equivalent to full enforcement behavior).
“t=y” — Testing mode. Receivers may apply a less strict interpretation of the published policy to allow safer validation during rollout.
This change simplifies policy deployment and removes ambiguity around partial enforcement percentages.
Retired DMARC Tags
Several existing tags have been removed from the specification:
- pct
The “pct” tag allowed administrators to apply DMARC enforcement to only a percentage of messages.
It was removed because email receivers often applied the intermediate percentages (for example, “pct=50”) incorrectly. RFC 9989 removes this complexity and replaces it with the simpler “t” tag. - rf
The “rf” tag specified the preferred format for failure reports.
Most receivers ignored this setting and generated reports using their own supported formats. - ri
The “ri” tag specified the requested interval between aggregate reports.
In reality, report delivery schedules have long been controlled by receiving providers, making the tag largely ineffective.
"What I like about RFC 9989 is what it removed. No more pct, no more PSL dependency, no more pretending RUF reports work at scale. After ten years of running DMARC infrastructure, that's the right kind of update."
Aliaksandr MarkauCo-founder & CTO at DMARKOFF and GlockApps, email security specialist with 20+ years of experience, Golang & ClickHouse expert. A happy father of two teenagers.
Clearer Guidance for Forwarding and Mailing Lists
The updated specification provides more specific guidelines on handling forwarded messages and mailing list traffic, as they can break SPF or DKIM alignment, causing legitimate messages to fail DMARC checks.
RFC 9989 emphasizes that mailbox providers should not rely solely on a sender's p=reject policy when making delivery decisions. Additional signals, such as authentication history, sending patterns, and other security checks, should also be considered.
For senders, this means that forwarding-related authentication failures can still occur, making ongoing DMARC monitoring important for identifying these edge cases.
What Should Senders Do Now?
The upside is that most organizations do not need to make immediate changes. Existing DMARC records remain valid and continue to function normally.
However, there are a few recommended updates:
- Consider adding the “np” tag.
The new “np” tag can help protect against spoofing attempts that use non-existent subdomains. - Remove the “pct” tag.
Since “pct” is no longer part of the specification, it can be safely removed from your DMARC record. - Continue monitoring your reports.
Ongoing DMARC report analysis provides visibility into your authentication issues, unauthorized senders, or policy failures, and remains essential for maintaining domain health and compliance with sender requirements.
Does Your DMARC Tool Support the Latest Updates?
It's helpful to check if your DMARC monitoring tool is compatible with the latest specifications to ensure that your authentication setup and report processing function reliably.
However, when you use DMARKOFF, you can set those concerns aside, as it is designed to stay aligned with evolving DMARC standards, including the changes introduced in RFC 9989.
With our platform, you can easily:
- Monitor DMARC, SPF, and DKIM authentication results
- Identify unauthorized sending sources
- Detect authentication failures and anomalies
- Receive smart alerts about suspicious activity
- Analyze DMARC reports with Luma, the built-in AI assistant
- Safely collaborate across teams, clients, and departments
When processing reports and calculating domain analytics, DMARKOFF incorporates the latest DMARC standards, supporting updated record syntax and policy discovery mechanisms to provide accurate report monitoring.
Conclusion
The publication of RFC 9989, RFC 9990, and RFC 9991 marks an important milestone for DMARC. Rather than introducing a completely new protocol, these updates refine and formalize a technology that has already become a core part of modern email security.
One of the most notable changes is that DMARC has moved from Informational status to a Proposed Standard on the IETF Standards Track. This reflects how widely the protocol is used today and its growing importance for responsible email sending.
The good news for domain owners is that existing DMARC deployments continue to work. Most organizations won't need to rebuild their records or change their policies. However, now is a great time to review your records, remove deprecated tags, explore new options like the “np” tag, and ensure your monitoring tools support the latest standards.
The real value for domain owners still lies in maintaining constant oversight of their email system. Continuous report analysis helps identify authentication issues, prevent domain abuse, and ensure compliance as email authentication standards develop.
FAQ
No. The update of your existing DMARC records is not mandatory. However, reviewing older records for deprecated tags such as “pct”, “rf”, and “ri” is recommended.
No. The core DMARC authentication model remains the same. Messages still pass DMARC when the visible “From” domain aligns with either SPF or DKIM authentication. RFC 9989 primarily updates policy discovery, reporting specifications, and record syntax rather than changing how DMARC evaluates email messages.
No, there is no mentioned deadline. Receivers may continue to tolerate pct during a transition period. However, since the pct behavior was already implemented inconsistently across providers, leaving it in your record adds noise without benefit. Removing it (and replacing gradual rollouts with the new t=y testing flag) is a clean, low-risk improvement to make at your next record review.
“Proposed Standard” is the first step on the IETF Standards Track, below “Internet Standard.” This designation means DMARC has passed rigorous community review and is considered stable, reliable, and ready for widespread deployment. In practice, Proposed Standards are considered stable and ready for deployment. Reaching full “Internet Standard” status requires multiple independent implementations and significant operational experience.
Author of numerous articles on email deliverability and email authentication. She is known for her practical, data-driven approach that helps teams get more emails into inboxes and keep sending practices healthy.
Julia works closely with senders every day, providing technical support, troubleshooting deliverability issues, and making complex topics such as email infrastructure, authentication, and sender reputation easier to understand and deal with.