RFC 9989: What’s New in the Latest DMARC Specification

On May 20, 2026, DMARC reached an important milestone with the publication of RFC 9989, officially replacing RFC 7489 from 2015. Unlike its predecessor, which was published as an informational RFC, RFC 9989 is now on the Internet Standards Track as a Proposed Standard.

That said, this is not a major redesign of DMARC. The protocol itself works largely the same way, DMARC records still begin with v=DMARC1, and most domain owners will not need to change their existing policies. RFC 9989 primarily clarifies terminology, tightens definitions, and standardizes behavior that had previously been implemented inconsistently. Still, there are several notable additions and changes worth understanding.

New t Tag Replaces pct for Testing

RFC 7489 introduced the pct tag, which allowed domain owners to apply DMARC enforcement to only a percentage of failing messages. In practice, however, values other than 0 and 100 were implemented inconsistently across mail receivers.

RFC 9989 replaces this behavior with the simpler t tag, which supports only two values:

• t=y: Indicates that the domain owner is testing DMARC enforcement. If the DMARC policy is set to quarantine, failing messages are treated as if the policy were none. If the policy is reject, failing messages are quarantined instead.
• t=n (default): DMARC policy is enforced normally according to the p, sp, or np tags.

This removes ambiguity and makes testing behavior more predictable across implementations.

New np Tag Sets Policy for Non-Existent Domains

The new np tag allows domain owners to define a DMARC policy specifically for non-existent subdomains.

Under RFC 7489, the sp tag applied only to existing subdomains, leaving non-existent subdomains without explicit policy coverage. This gap could be abused by attackers spoofing addresses from randomly generated subdomains.

The np tag follows the same syntax as p and sp:

• np=none: No enforcement for non-existent subdomains.
• np=quarantine: Messages from non-existent subdomains are treated as suspicious.
• np=reject: Messages from non-existent subdomains should be rejected.

If the np tag is absent, receivers fall back to sp, or to p if sp is also missing.

New psd Tag Identifies Public Suffix Domains

RFC 9989 introduces the psd tag, which allows a domain owner to indicate whether a domain is a public suffix domain (PSD).

A PSD is a domain under which third parties can register subdomains, such as .com or .co.uk. Distinguishing PSDs from organizational domains is important because DMARC policy discovery depends on identifying the correct organizational boundary.

The psd tag supports three values:

• psd=y: The domain is a public suffix domain.
• psd=n: The domain is an organizational domain controlled by a single entity.
• psd=u (default): PSD status is unspecified.

This tag plays a key role in the new DNS Tree Walk algorithm described later in the RFC.

Removal of rf and ri Tags

RFC 9989 removes the rf and ri tags from DMARC policy records and marks them as historic.

• rf (report format) previously allowed domain owners to specify the format of failure reports. In practice, the only widely used value was afrf.
• ri (report interval) allowed domain owners to request a reporting interval in seconds for aggregate reports. Most receivers ignored this value and used their own schedules instead.

Because these tags were either effectively fixed or widely ignored, they were removed from the standard.

Removal of the Maximum Report Size Parameter

RFC 9989 also removes the ability to specify a maximum report size using the ! modifier in reporting URIs.

For example, older DMARC records could include:

rua=mailto:reports@example.com!5m

This requested a maximum aggregate report size of 5 MB. In practice, however, most receivers enforced their own limits and ignored the parameter.

DMARC Reporting Moved to Separate RFCs

Aggregate and failure reporting are no longer defined directly within the core DMARC specification.

Instead, RFC 9989 references two separate RFCs:

• RFC 9990 – DMARC Aggregate Reporting
• RFC 9991 – DMARC Failure Reporting

Separating reporting from core policy enforcement allows the reporting formats and schemas to evolve independently without requiring updates to the main DMARC specification.

DNS Tree Walk Replaces the Public Suffix List

One of the most important changes in RFC 9989 is the replacement of the Public Suffix List (PSL) approach with a DNS Tree Walk algorithm.

Determining the organizational domain is essential for two parts of DMARC:

• DMARC policy discovery: If a domain does not publish a DMARC record, receivers look for a policy at the organizational domain.
• Identifier alignment: Under relaxed alignment, DMARC verifies that the From domain shares the same organizational domain as the SPF or DKIM-authenticated domain.

Under RFC 7489, implementations were expected to use a Public Suffix List to determine the organizational domain. However, the RFC did not mandate a specific PSL source or update strategy, which resulted in inconsistent behavior across implementations.

RFC 9989 replaces this with a DNS-based discovery mechanism that dynamically determines the organizational domain using live DNS lookups.

The DNS Tree Walk works as follows:

1. Prepend _dmarc. to the current domain and query DNS for a DMARC record.
2. If a valid DMARC record is found containing psd=n or psd=y, stop:
   • psd=n means the current domain is the organizational domain.
   • psd=y means the current domain is a public suffix domain, so the domain one level below it is treated as the organizational domain.
3. If no matching DMARC record is found, remove the left-most label and repeat the process.
4. To prevent excessive DNS queries, the algorithm limits processing to seven labels.
5. If no DMARC record is found during the walk, the original domain is treated as the organizational domain.

For example, when evaluating:

a.b.c.d.e.f.g.h.i.j.mail.example.com

the DNS Tree Walk would check the following locations in order:

• _dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
• _dmarc.g.h.i.j.mail.example.com
• _dmarc.h.i.j.mail.example.com
• _dmarc.i.j.mail.example.com
• _dmarc.j.mail.example.com
• _dmarc.mail.example.com
• _dmarc.example.com
• _dmarc.com

Compared to the PSL approach, this method is more dynamic, avoids reliance on external lists, and provides explicit control through the psd tag.

What You Should Do Next

For most domain owners, no immediate action is required.

Typical DMARC deployments with a single DMARC record at the organizational domain will continue to work as before. Most of the changes primarily affect public suffix operators, large organizations with delegated DNS structures, and DMARC software implementers.

If your DMARC record still includes deprecated tags such as pct, rf, or ri, there is no urgent need to remove them. Both RFC 7489 and RFC 9989 specify that unknown tags must be ignored, so older configurations will continue to function.

That said, there are several new features worth adopting:

• Add t=y if you previously used pct=0 to indicate testing mode.
• Add psd=n to explicitly identify your organizational domain and reduce unnecessary DNS lookups.
• Add np=quarantine or np=reject to protect against spoofing of non-existent subdomains.

If you process DMARC reports using a custom XML parser, review RFC 9990 and RFC 9991 carefully, as both introduce updated schemas.

Public suffix operators, such as operators of com, co.uk, or shared hosting domains like azurewebsites.net, should publish DMARC records with psd=y to ensure correct DNS Tree Walk behavior.

Organizations with complex delegated DNS structures should verify that their DMARC policies behave as expected under the new algorithm. Some mail receivers may continue using older PSL-based logic for some time, which could lead to inconsistent organizational domain detection.

To minimize ambiguity, organizations can:

• Explicitly publish psd=n on organizational domains.
• Use strict alignment with adkim=s and aspf=s.
• Publish DMARC records for every domain that sends mail.

Mail receivers and DMARC implementers should update their software to support DNS Tree Walk processing, recognize the new t, psd, and np tags, and ignore deprecated tags appropriately.

Conclusion

RFC 9989 is more of an evolutionary update than a revolutionary one. It does not introduce breaking changes, and most existing DMARC deployments will continue working without modification.

The biggest improvements are increased consistency, better handling of non-existent subdomains, and a standardized replacement for the Public Suffix List approach.

If you want to verify that your setup behaves correctly under the updated specification, you can test it with our DMARC Checker. Simply send a test email to the address provided on the site, and it will analyze your DMARC, DKIM, and SPF configuration with full support for RFC 9989.