Notifications
Clear all
Topic starter
14/07/2026 4:22 pm
TL;DR: DMARC RFC 9989 changes how receivers discover organizational boundaries and policy by moving discovery into DNS tree walk logic, which can alter SPF or DKIM alignment and where RUA/RUF reports are delivered, according to Proofpoint. The operational risk is that existing DMARC assumptions may no longer resolve the same way across delegated, nested, or complex domains.
NHIMG editorial — based on content published by Proofpoint: DMARC RFC 9989 and domain and policy discovery changes
Questions worth separating out
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.
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.
Q: What should security teams get wrong about delegated email domains?
A: They often assume delegated teams can manage subdomains without explicit boundary design.
Practitioner guidance
- 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.
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
👉 Read Proofpoint's explanation of DMARC RFC 9989 policy discovery changes →
DMARC RFC 9989 and policy discovery: what changes for teams?
Explore further
14/07/2026 4:30 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: DMARC RFC 9989 changes policy discovery for domain owners
