Notifications
Clear all
Topic starter
14/07/2026 4:21 pm
TL;DR: DMARC RFC 9989 adds tags for non-existent subdomains, delegated namespace boundaries, and testing state, while leaving receivers to adopt the new model at different speeds, according to Proofpoint. That makes explicit cross-version records, not minimalist records, the practical control for predictable email authentication outcomes.
NHIMG editorial — based on content published by Proofpoint: DMARC RFC 9989 technical guidance for policy intent and receiver transition
Questions worth separating out
A: Publish records that remain explicit under both old and new DMARC behavior, then test against the receiver mix you actually use.
Q: Why do delegated domains complicate DMARC governance?
A: Delegated domains complicate governance because the team that owns the namespace may not control the apex domain, reporting path, or policy boundary.
Q: What breaks when non-existent subdomain handling is not explicit?
A: When non-existent subdomain handling is vague, receivers may fall back to broader subdomain behavior and treat lookalike names more permissively than intended.
Practitioner guidance
- Publish explicit cross-version DMARC records Keep RFC 7489-era tags and RFC 9989 tags in place during the transition window so older and newer receivers can interpret the same policy intent consistently.
- Define delegated namespace boundaries deliberately Use psd only where a delegated team truly owns the namespace boundary and must manage its own reporting and policy decisions.
- Harden protection against fake subdomains Apply np in environments where brand abuse through non-existent subdomains is plausible, and test how your receivers handle lookalike names that do not exist in DNS.
What's in the full article
Proofpoint's full blog covers the operational detail this post intentionally leaves for the source:
- Receiver-side compatibility guidance for mixed RFC 7489 and RFC 9989 environments.
- The exact tag combinations Proofpoint recommends during transition, including when to keep legacy fields explicit.
- Namespace boundary examples for delegated domains that need their own policy and reporting ownership.
- Testing and monitoring considerations for moving from validation to enforcement without losing visibility.
👉 Read Proofpoint's technical guide to DMARC RFC 9989 transition controls →
DMARC RFC 9989 and receiver transition: are your controls ready?
Explore further
14/07/2026 4:29 pm
RFC 9989 turns DMARC from a broad policy signal into a more explicit domain governance mechanism. The standard matters because domain ownership is often distributed across business units, subsidiaries, and delegated namespaces, not concentrated at a single apex domain. When policy intent is implicit, enforcement becomes uneven and hard to troubleshoot. For identity and fraud teams, the practical conclusion is that policy clarity is now part of trust architecture, not just mail configuration.
A question worth separating out:
Q: How do you know if DMARC testing mode is actually working?
A: You know testing mode is working when failures are being reviewed, causes are separated between legitimate mail and abuse, and the policy owner can show a clear path to enforcement. Without that operational loop, testing becomes a permanent holding pattern rather than a control maturity step.
👉 Read our full editorial: DMARC RFC 9989 raises the bar for domain policy precision
