Email authentication standards must evolve to keep pace with new threats and changes in how organizations send and receive email. In this blog, we cover recent enhancements to one of the most widely adopted email authentication protocol frameworks: Domain-based Message Authentication, Reporting, and Conformance (DMARC). We also explain how the updated protocol, DMARC RFC 9989, affects organizational domain and policy discovery, and what to consider before making enforcement decisions. 

Series note 

For a broader overview of the standard, see the introductory blog. This article focuses specifically on domain and policy discovery impact, while Part 2 (‘How to Use the New Tags’) and Part 3 (‘Prepare for Enforcement’) of the series provide deeper detail about other aspects of DMARC RFC 9989. 

 

Key takeaways 

DMARC RFC 9989 is the updated DMARC standard, published in May 2026, that changes how receivers discover domain boundaries and apply policy, making it important for domain owners to understand where outcomes may differ from original DMARC. 

• DMARC helps with inbox delivery for legitimate mail and gives domain owners control over how unauthorized mail is handled when it fails both Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) authentication. DMARC RFC 9989 enhances these capabilities but introduces operational changes that can affect alignment and the applied policy for DMARC failures. 
• DMARC RFC 9989 can change which DMARC policy is applied, whether SPF or DKIM align, and whether RUA/RUF reports are sent to the expected location.  
• DMARC RFC 9989 gives domain owners a more DNS-native way to express domain boundaries and policy when compared with Public Suffix List-defined top-level domains used by DMARC RFC 7489.  
• Domain owners must identify where RFC 9989 produces a different result than original DMARC: a different resolved record that could affect applied policies and RUA/RUF report locations, and/or a different Organizational Domain that could affect alignment. 

Original DMARC (RFC 7489) vs. DMARC RFC 9989 

Let’s begin with an overview of some key updates in DMARC RFC 9989. 

Area	RFC 7489-era behavior	DMARC RFC 9989 behavior	Why it matters
Organizational Domain discovery and boundary signaling	Relied heavily on Public Suffix List-based domain discovery. Offered limited ability for a delegated DNS owner to define a lower-level organizational boundary.	Uses DNS Tree Walk and DNS-published boundary signals. New DMARC policy flags enable flexible organizational domain demarcations:  ‘psd=n’ marks a domain as the Organizational Domain; ‘psd=y’ marks a Public Suffix Domain.	The Organizational Domain can differ. Universities, government agencies, and large enterprises can express delegated ownership more precisely and in the way that makes sense for their organizations.
Policy discovery	Policy was inherited from an organizational domain, when possible, if not published on the Author Domain.	The receiver checks the Author Domain, then the Organizational Domain, then the Public Suffix Domain. The Organizational Domain can be different under DMARC RFC 9989 than it was under DMARC RFC 7489.	The effective policy may come from a different record than expected, including the Public Suffix Domain. If RUA/RUF addresses differ, then visibility may also shift away from the expected destination.
Subdomain policy	‘p’ and ‘sp’ handled domain and subdomain policy.	‘np’ adds specific handling for non-existent subdomains.	Email that uses non-existent subdomains can be handled with a designated policy.
Testing and transition	‘pct’ was commonly used for rollout signaling, with uneven interpretation.	‘t’ signals testing mode as binary yes or no.	Records should remain explicit and compatible during transition.

 

DNS Tree Walk: moving Organizational Domain and policy discovery to DNS 

Under DMARC RFC 9989, receivers perform a DNS Tree Walk. The Tree Walk discovers the DMARC Organizational Domain and policy without reliance on the Public Suffix List (PSL). Additional details about the ‘psd’ tag is provided in a subsequent blog in this series. 

Step 1: Organizational Domain discovery 

DMARC RFC 9989 uses DNS Tree Walk to identify an Organizational Domain. The new ‘psd’ tag moves domain boundary signals into DNS, deprecating use of the Public Suffix List.  

Overview: The Tree Walk begins at the Author Domain and traverses the domain levels until a valid DMARC record is found that contains ‘psd=n’ or ‘psd=y’. If no ‘psd’ signal is found, the receiver applies fallback logic to determine the Organizational Domain. 

 

 

Details: 

• Begin at the Author Domain. 
• If a valid DMARC record exists with a ‘psd’ tag of ‘y’ or ‘n’, the Tree Walk stops. Note: ‘psd=u’ is the default value and does not stop the Tree Walk. 

PSD result	Meaning	Organizational Domain
psd=y	Current domain is the Public Suffix Domain	One label to the left
psd=n	Current domain is the Organizational Domain	Current domain

• Otherwise, the leftmost label is removed (everything to the left of the leftmost period), and the resulting domain is queried for a valid DMARC record that contains a ‘psd’ value of ‘y’ or ‘n’. Organizational Domain discovery stops when the ‘psd’ tag is observed with a value of ‘y’ or ‘n’. 

Example Tree Walk: 

Author Domain: 
eu.sales.example.gov 
 
DNS Tree Walk:  
_dmarc.eu.sales.example.gov 
_dmarc.sales.example.gov 
_dmarc.example.gov 
_dmarc.gov 

To protect against denial-of-service attacks, a maximum of eight queries are performed for a domain. For a domain with more than eight labels (for example, a.b.c.d.e.f.g.h.i.j.mail.example.com), the Author Domain is queried first, and if the Tree Walk must continue, it resumes at the domain identified by the rightmost seven labels (such as g.h.i.j.mail.example.com). 

• A fallback applies if an Organizational Domain cannot be determined through the Tree Walk: 
  • The domain with the fewest labels that has a valid DMARC record is identified as the Organizational Domain.
  • If no valid DMARC record exists, the author domain is the Organizational Domain. 

Step 2: Policy discovery 

 

The effective DMARC policy is determined in this order: 

• Use the DMARC record on the Author Domain. 
• If none is available, use the DMARC record on the Organizational Domain. 
• If none is available, use the DMARC record on the Public Suffix Domain. 
• If none exists, no DMARC policy applies. 

RFC 9989 Tree Walk and policy discovery examples 

Example 1: Organizational Domain and Policy Discovery - Policy on Author Domain 

 

 

Example 2: Organizational Domain and Policy Discovery - Policy on Public Suffix Domain 

 

Example 3: Delegated namespace with an explicit boundary 

Consider a medical school that manages its own sending systems and DNS subtree, while the central university team controls the apex domain. The author domain is alerts.medicine.university.edu 

 

In this example, medicine.university.edu is treated as the Organizational Domain because its DMARC record includes ‘psd=n’. That may be the right result when the medical school controls its namespace, vendors, reporting, and remediation process. The applied policy comes from medicine.university.edu because DMARC records are retrieved from the Organizational Domain, when available, if none exists on the Author Domain. 

Example 4A: Original DMARC and DMARC RFC 9989 result in different boundaries 

 

Example 4B: Original DMARC and DMARC RFC 9989 result in different boundaries 

 

 

Why this affects your program and what to assess 

DMARC RFC 9989 can change which DMARC policy is applied, whether SPF or DKIM aligns, and whether RUA/RUF reports are sent to the expected location. This is especially important for organizations with complex or delegated domain structures. The impact comes from how RFC 9989 discovers policy and determines the Organizational Domain through DNS Tree Walk. 

For each active Author Domain, evaluate the following: 

What to check	Why it matters
Does the applied policy differ between original DMARC / RFC 7489 and DMARC RFC 9989?	RFC 9989 may discover a different DMARC record than original DMARC. A different resolved policy can change the requested handling for failed mail and could change the destination of RUA/RUF reports.
Is the Organizational Domain different?	A different Organizational Domain can change SPF or DKIM alignment outcomes.
Does SPF or DKIM still align?	Check alignment. If the selected boundary changes, mail that aligned before may no longer align, or mail that previously failed may now pass.
Is psd being used intentionally?	A delegated team may be able to express its own boundary if it controls the relevant DNS node. Domains may also inherit policies from a Public Suffix Domain.
Is the Author Domain deeply nested?	RFC 9989 Tree Walk is limited to a maximum of eight levels. A deeply nested Author Domain may require an explicit DMARC record at the Author Domain if a specific policy must apply.
Could np affect the result?	If the Author Domain is non-existent, the np tag may change the policy applied to that message. This is covered in more detail in Blog 2 of the series.

The practical goal is to identify where RFC 9989 produces a different result than original DMARC: a different resolved record that could affect applied policies and RUA/RUF report locations, and/or a different Organizational Domain that could affect alignment. 

How Proofpoint can help 

Domain owners should assess their domains for instances where RFC 9989 Organizational Domain and policy discovery differ from DMARC RFC 7489, understand the implications, and adjust records as needed before policy decisions create surprises. 

Proofpoint Email Fraud Defense (EFD) recognizes the importance of preparing for the transition to DMARC RFC 9989. EFD analyzes each of your domains twice: once for original DMARC, and once for DMARC RFC 9989, giving you a comprehensive view of effective policies and record contents, including new DMARC tags. EFD provides a clear signal when the resolved policy differs across DMARC standards, making it easier to prioritize investigation for domains where outcomes may change. Proofpoint Professional Services consultants can also support you with DMARC and email security expertise. 

 

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.