DMARC RFC 9989 changes policy discovery for domain owners

At a glance

What this is: DMARC RFC 9989 updates DMARC discovery so receivers may resolve different organizational boundaries, policies, and reporting destinations than RFC 7489.

Why it matters: That matters because identity and email security teams need to verify that authentication, alignment, and reporting still behave as expected across delegated domains and subdomains.

👉 Read Proofpoint's explanation of DMARC RFC 9989 policy discovery changes

Context

DMARC RFC 9989 changes how email authentication policy is discovered, which means the same sending domain can now resolve differently depending on DNS structure and boundary signals. For teams responsible for domain governance, the main issue is not whether DMARC still exists, but whether the receiver arrives at the same organizational boundary and policy outcome as before.

This is an identity governance problem as much as an email authentication one. Domain owners, delegated business units, and security teams need to understand where policy ownership lives, how alignment is determined, and whether reporting lands with the team that can actually act on it.

Key questions

Q: How should teams test DMARC changes before moving to enforcement?

A: Test each sending domain against both the original DMARC discovery model and RFC 9989, then compare the resolved organizational domain, policy source, alignment outcome, and reporting destination. Do this for delegated and nested namespaces first, because those are the places where enforcement surprises are most likely.

Q: Why can DMARC policy discovery change even when the DNS record seems unchanged?

A: Because RFC 9989 changes the discovery process, not just the record content. Receivers may walk the DNS tree differently, stop at a different boundary, or inherit policy from a different level, which can alter the effective policy and the organization that receives reports.

Q: What should security teams get wrong about delegated email domains?

A: They often assume delegated teams can manage subdomains without explicit boundary design. In practice, if the DNS tree and DMARC signals are not aligned, receivers may resolve authority and policy at a different level than the business owner expects, creating gaps in accountability and visibility.

Q: Who is accountable when DMARC enforcement behaves differently after an update?

A: The accountable party is the domain owner, but the operational response usually spans messaging, identity, and DNS teams. If RFC 9989 changes the applied policy or reporting destination, ownership has to be documented at the organizational domain level, not only at the sending application level.

Technical breakdown

DNS tree walk and organizational domain discovery

RFC 9989 replaces heavy reliance on the Public Suffix List with a DNS tree walk that starts at the author domain and moves upward until it finds a usable DMARC record with a boundary signal. The key change is that boundary discovery is now expressed in DNS through the psd tag, which lets a domain declare itself as a public suffix domain or an organizational domain. That makes discovery more precise in delegated structures, but it also makes the outcome dependent on how the DNS tree is published and maintained.

Practical implication: Validate every delegated namespace where DNS boundary signals could change the organizational domain result.

Policy resolution and alignment outcomes under RFC 9989

After boundary discovery, receivers evaluate policy in a fixed order: author domain first, then organizational domain, then public suffix domain. That sequence matters because the effective policy may come from a different record than teams expect, and the resolved organizational domain can change SPF or DKIM alignment decisions. In practice, a domain that passed or failed under RFC 7489 may produce a different result once the new discovery logic is applied. This is why policy evaluation has to be tested, not assumed.

Practical implication: Compare RFC 7489 and RFC 9989 results for every active sending domain before changing enforcement.

Non-existent subdomains and transition controls

RFC 9989 adds the np tag for non-existent subdomains and uses t as a simple testing indicator, which tightens how receivers interpret rollout intent. The important technical point is that a failed or non-existent author domain can now influence policy selection in ways that differ from older pct-based expectations. For large organisations with nested business units, this makes transition states more explicit but also increases the need for careful record hygiene. The receiver will follow the published logic, not the team’s assumption about intended behavior.

Practical implication: Audit non-existent subdomain handling and transition tags before moving any domain into enforcement.

NHI Mgmt Group analysis

DMARC boundary discovery is now an identity governance issue, not just a mail-authentication detail. RFC 9989 changes where authority is inferred in the DNS hierarchy, so the team that owns a sending domain may no longer be the team that receives the effective policy or reports. That shifts operational control and accountability across domain owners, delegated business units, and security teams. Practitioners should treat boundary discovery as part of governance design, not as a one-time DNS setting.

Policy drift is the real risk when organizational domain discovery changes. The article shows that RFC 9989 can produce a different policy source, a different alignment result, or a different report destination than RFC 7489. That creates a gap between published policy and operational reality, especially in large enterprises with nested or delegated namespaces. The practical conclusion is that DMARC must be tested against both discovery models wherever transition could change enforcement.

Delegated namespaces need explicit ownership signals or they will inherit ambiguity. The medical-school example illustrates the governance value of a clearly declared boundary, but it also shows how easily reporting and enforcement can move if the DNS tree is not designed intentionally. That is the point of this update: domain delegation only works cleanly when ownership, boundary, and reporting path are aligned. Teams should map those three elements together rather than treating them as separate tasks.

DMARC RFC 9989 makes enforcement readiness depend on discovery correctness. The standard does not merely change syntax. It changes which record gets trusted, which means enforcement decisions can be right for one discovery path and wrong for another. Security and identity leaders should treat this as a boundary-validation exercise across the full domain portfolio, especially where business units operate semi-independently.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That fragmentation and behavior gap make boundary clarity in identity-adjacent controls harder to sustain, which is why teams should pair DMARC changes with broader lifecycle and governance review.
• signals_paragraphs

What this signals

Boundary drift becomes harder to manage when governance is already fragmented. Organisations that run multiple secrets and identity control planes often struggle to keep one authoritative view of ownership, reporting, and enforcement. That is exactly the kind of environment where a DMARC discovery change can expose hidden assumptions about who really controls a domain and who actually receives the signal.

Domain governance should now be reviewed alongside lifecycle ownership and reporting paths. The practical question is not whether RFC 9989 is technically sound, but whether your programme can prove that domain boundaries, policy sources, and response ownership still line up after discovery changes. If they do not, the issue is governance design, not just DNS hygiene.

For practitioners

• Compare discovery results across both DMARC versions Run each active author domain through RFC 7489 and RFC 9989 logic, then document any differences in organizational domain, applied policy, SPF alignment, DKIM alignment, and report destination.
• Map delegated ownership to DNS boundary signals For sub-brands, schools, regions, and business units, confirm who owns the author domain, who owns the organizational domain, and whether psd=n or psd=y expresses the intended boundary.
• Verify reporting paths before enforcement changes Check whether RUA and RUF destinations still land with the operational team that can investigate failures, especially where policy resolution may shift to a parent or public suffix domain.
• Test non-existent subdomain handling separately Review domains that depend on the np tag so that invalid or missing subdomains do not inherit an unintended policy during rollout or enforcement.

Key takeaways

• DMARC RFC 9989 changes the discovery model, so teams must validate whether policy, alignment, and reporting still resolve to the same place.
• Delegated and nested domains are the highest-risk areas because boundary signals in DNS can shift ownership and enforcement outcomes.
• Practical readiness means testing both discovery paths before enforcement, then fixing any mismatch between technical resolution and operational ownership.

Key terms

• Organizational Domain: The domain level a receiver treats as the policy and ownership boundary for DMARC evaluation. Under RFC 9989, that boundary may be derived from DNS-published signals rather than only from public suffix logic, so teams must confirm it matches operational responsibility.
• DNS Tree Walk: A discovery process that starts at the author domain and moves through parent labels until a valid boundary or policy record is found. In DMARC RFC 9989, this determines which domain is treated as authoritative and can change enforcement outcomes for delegated namespaces.
• Policy discovery: The process of finding and consolidating authorization rules that already exist across systems. It gives security teams a current view of how access is actually governed, including duplicates, conflicts, and gaps that can remain hidden when controls are managed in separate tools.

What's in the full article

Proofpoint's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how RFC 9989 resolves different organizational domains across nested DNS structures
• The full decision flow for psd=y, psd=n, and fallback behavior in complex delegated environments
• More worked examples showing when RUA and RUF reporting destinations change under the new discovery rules
• Guidance on preparing records before enforcement so domain owners can reduce unexpected alignment changes

👉 Proofpoint's full post includes the DNS tree walk examples and enforcement checks

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.