Blog
Threat Protection
DMARC RFC 9989 Part 2: How to Use the New Tags
Connect fiber

DMARC RFC 9989 Part 2: How to Use the New Tags

Share with your network!
Abby Berger

This is the second blog in a three-part series. In the first installment, we reviewed DMARC RFC 9989, explored its impact on Organizational Domain and DMARC policy discovery, and outlined key considerations before moving to enforcement. The third installment outlines a measured path to adopting RFC 9989 updates as both a Domain Owner and a DMARC enforcer. 

In this blog, we take a deeper technical dive into RFC 9989, focusing on how the new tags can be used to express policy intent more precisely. We also examine strategies for maintaining interoperability and predictable policy outcomes as email receivers adopt the standard at different rates. 

Key takeaways 

DMARC RFC 9989 introduces new tags that help domain owners express policy intent, define domain boundaries, and support a more predictable transition from RFC 7489-era behavior. 

  • The new DMARC RFC 9989 tags offer incremental value beyond RFC 7489.  
    • ‘np’ helps address non-existent subdomain abuse. 
    • ‘psd’ expresses intentional domain boundaries. 
    • ‘t’ signals testing and replaces the ‘pct’ tag. 
  • The following RFC 7489 tags are deprecated in RFC 9989: ‘pct’, ‘rf’, and ‘ri’. 
  • Receiver adoption of RFC 9989 will be phased. Cross-version records are recommended to provide explicit policy guidance to all receivers, regardless of whether they enforce original DMARC or RFC 9989. 

DMARC 9989 receiver enforcement 

The transition to DMARC RFC 9989 creates a practical challenge: not every receiver will adopt the new behavior at the same time. Some receivers may continue to apply RFC 7489-era behavior, while others evaluate records using the updated RFC 9989 model. Your record should reduce ambiguity during that transition. 

Recommendation: publish a complete cross-version record during transition 

During the adoption window, include the complete DMARC RFC 7489 and DMARC RFC 9989 tag set in your DMARC record, with intentional values. This gives both older and newer receivers explicit guidance and makes your intended policy easier to inspect, monitor, and troubleshoot. 

Example transition-oriented record: 

v=DMARC1; p=quarantine; sp=none; np=reject; psd=n; t=n; 
adkim=r; aspf=r; fo=1; pct=100; rf=afrf; ri=86400; 
rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com

This example demonstrates the pattern: keep legacy-relevant tags explicit while adding RFC 9989 tags that clarify non-existent subdomain handling, domain boundaries, and testing state. 

Use the ‘psd’ tag to define boundaries in delegated domain namespaces 

The ‘psd’ tag lets domain owners express a DMARC boundary in DNS, replacing the Public Suffix List-based approach used by original DMARC. This is especially useful for nested or delegated environments where the team responsible for a namespace cannot easily update the apex domain. 

_dmarc.medicine.university.edu 
v=DMARC1; p=quarantine; sp=reject; np=reject; psd=n; rua=mailto:dmarc_rua@emaildefense.proofpoint.com;

In this example, ‘medicine.university.edu’ is treated as the Organizational Domain by receivers applying DMARC RFC 9989. That allows the delegated team to define its own boundary, receive its own reports, and manage policy for its namespace. 

Use ‘psd=n’ only when that DNS node should truly act as the Organizational Domain, then validate SPF, DKIM, reporting, and policy behavior against that boundary. 

The default value is ‘psd=u’, representing ‘unknown’ or ‘default.’ The Tree Walk does not stop for the default value. 

Use the ‘np’ tag to control non-existent subdomain abuse 

The non-existent subdomain policy, ‘np’, lets you express how receivers should handle DMARC failures from subdomains that do not exist in DNS. A non-existent subdomain is a domain below your Organizational Domain that looks like part of your namespace but has no DNS record. 

v=DMARC1; p=quarantine; sp=none; np=reject; rua=mailto:dmarc_rua@emaildefense.proofpoint.com;

In this pattern, you can keep a cautious policy for known subdomains while asking receivers to reject failed mail that uses non-existent subdomains, such as fake-login.hr.example.com.  

There is no default value for this tag. The ‘sp’ tag applies in its absence. If no ‘sp’ tag is present, the ‘p’ tag applies. 

Use the ‘t’ tag to signal testing, not to replace monitoring 

The ‘t’ tag signals testing mode under DMARC RFC 9989. It tells receivers that the domain owner is testing policy application and to apply failure handling one level below the stated policy. It replaces the ‘pct’ tag, with a value of ‘t=y’ being the equivalent of ‘pct=0’, and ‘t=n’ equivalent to ‘pct=100’. 

v=DMARC1; p=reject; sp=quarantine; np=reject; t=y; 
rua=mailto:dmarc_rua@emaildefense.proofpoint.com;

When testing, you still need to know which senders fail, whether SPF or DKIM aligns, whether the selected Organizational Domain changed, and whether the failures are legitimate mail or abuse. Use ‘t=y’ with active monitoring and clear exit criteria. 

The default value, if no ‘t’ tag is specified, is ‘t=n’. 

Keep legacy-relevant tags explicit while email receivers transition 

Because email receiver adoption of DMARC RFC 9989 will be uneven, do not remove RFC 7489-era tags simply because RFC 9989 updates the model. Instead, maintain a complete, explicit record during the transition so both older and newer DMARC-compatible receivers have the information they need. Keep RFC 7489-era tags such as ‘pct’, ‘rf’, and ‘ri’ during transition where your program or receivers still depend on them. 

  • Review every DMARC record for complete RFC 7489 and RFC 9989 tag coverage during the receiver transition period. 
  • Add ‘psd’ only where boundary signaling is intentional. Use ‘psd=n’ only where a delegated DNS node should act as the Organizational Domain, and ‘psd=y’ only where a domain should act as the Public Suffix Domain. 
  • Use the new ‘np’ tag to protect against non-existent subdomain abuse. 
  • Use ‘t=y’ only with active monitoring and defined exit criteria. 
  • Keep ‘adkim’ and ‘aspf’ explicit when alignment mode is a deliberate policy choice. 
  • Keep ‘rua’ and ‘ruf’ populated and aligned with reporting operations, privacy requirements, and remediation ownership.

How Proofpoint can help 

Proofpoint Email Fraud Defense Professional Services collaborates with customers to support cross-version DMARC compatibility and effective record content. Proofpoint Email Fraud Defense can help identify domains and subdomains, highlight policy-resolution differences, surface non-existent subdomain activity, and help determine whether testing can safely move toward enforcement. 

 

Learn More 

Visit Proofpoint Email Fraud Defense to learn how Proofpoint can help you simplify DMARC deployment, improve email authentication, and accelerate your journey to enforcement. 

To learn how Proofpoint helps organizations defend against AI-scaled threats and advanced impersonation attacks across email and digital communications, visit Proofpoint Collaboration Security or contact your Proofpoint representative today.  

Previous Blog Post