DMARC RFC 9989 raises the bar for domain policy precision

At a glance

What this is: Proofpoint explains that DMARC RFC 9989 extends policy expression with tags for subdomain abuse, delegated boundaries and testing.

Why it matters: This matters because identity and email security teams need records that remain interpretable across mixed receiver adoption, especially where delegated domains, reporting ownership and enforcement timing affect phishing and spoofing outcomes.

Context

DMARC is an email authentication policy layer that tells receivers how to handle messages claiming to come from a domain. RFC 9989 matters because policy discovery and enforcement become harder when the sending domain has nested, delegated or changing namespace boundaries, and when receivers do not all adopt the same version at the same time.

The governance gap is not the absence of DMARC, but ambiguity during transition. For security and identity teams, that creates a control problem rather than a syntax problem: the record has to communicate intent clearly enough for older and newer receivers to reach the same practical outcome.

In that sense, the article is about precision in identity signals as much as email filtering. A DMARC record that leaves boundary handling implicit can undermine investigation, reporting and enforcement ownership across distributed domain structures.

Key questions

Q: What breaks when DMARC records do not express namespace boundaries clearly?

A: Receivers can interpret the same policy differently, especially in delegated or nested domains. That creates inconsistent quarantine, rejection and reporting outcomes, and it weakens the ability to prove which team owns the policy for a given namespace.

Q: Why do non-existent subdomains create phishing risk in DMARC?

A: Because attackers can invent hostnames below a trusted organisational domain and rely on receivers or users to treat them as legitimate. The risk is not just spoofing, but policy ambiguity that allows lookalike mail paths to avoid the handling the owner intended.

Q: How should teams manage DMARC during receiver transition?

A: Keep a cross-version record with explicit legacy and RFC 9989 tags until adoption is stable across the receiving ecosystem. That reduces inconsistent interpretation and makes troubleshooting possible when older and newer receivers behave differently.

Q: What should security teams do when DMARC testing mode is in use?

A: Use testing only with active monitoring, defined failure review and a clear exit plan. Testing should show which senders fail, whether alignment is working and whether the failures are legitimate mail or abuse, otherwise it becomes a permanent gray zone.

Technical breakdown

How RFC 9989 changes DMARC policy expression

RFC 9989 keeps DMARC as a DNS-published policy mechanism, but adds more explicit ways to describe how receivers should treat subdomains, boundary states and testing. The point is not to replace authentication signals from SPF and DKIM, but to make policy interpretation less dependent on receiver assumptions. That matters when namespaces are delegated, because the responsible team may not control the apex domain and therefore needs policy to travel with the managed boundary. The practical effect is a record that expresses intent rather than relying on inherited behavior.

Practical implication: treat DMARC as a governance record, not just an enforcement switch, and review whether your namespace structure needs explicit boundary tags.

Why cross-version DMARC records reduce transition risk

The article shows a transition problem that is common in protocol evolution: some receivers will understand RFC 9989 while others will continue with RFC 7489-era behavior. A cross-version record keeps legacy-relevant tags explicit while adding the new ones, so receivers have enough information regardless of their parsing model. That reduces the risk of inconsistent quarantine, rejection or reporting outcomes across the ecosystem. It also preserves inspectability, which is important when teams need to troubleshoot why one receiver applied a policy and another did not.

Practical implication: publish records that remain unambiguous to both old and new receivers until adoption stabilises across your sender and receiver population.

What the new tags do for delegated domains and subdomain abuse

The new tags described in the article address three separate control gaps. The psd tag lets a domain owner declare a boundary in a delegated namespace. The np tag tells receivers how to handle non-existent subdomain abuse, where an attacker invents a host below a legitimate organisational domain. The t tag signals testing and is not a substitute for monitoring. Together they make it easier to distinguish policy intent from accidental inheritance, which is essential when namespace complexity creates confusion between legitimate and spoofed mail paths.

Practical implication: map delegated domains, fake subdomains and testing states explicitly before moving records toward stricter handling.

Threat narrative

Attacker objective: The attacker wants to exploit namespace ambiguity so mail receivers trust messages that should have been rejected or quarantined.

1. Entry occurs when an attacker abuses lookalike or non-existent subdomains that sit below a legitimate organisational domain.
2. Credential access is not the main issue here; the attack relies on policy ambiguity and receiver interpretation rather than stolen credentials.
3. Impact is delivered when receivers accept or mishandle spoofed mail, allowing impersonation, phishing or domain abuse to succeed.

Breaches seen in the wild

• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy precision has become a control plane problem, not a formatting preference. DMARC records now need to communicate intent across mixed receiver populations, delegated namespaces and transition states. When the same record can be interpreted differently, governance breaks before enforcement does. Practitioners should treat explicit policy expression as part of mail security architecture, not an administrative detail.

Delegated domain boundaries need first-class identity governance. The psd tag is important because ownership in email namespaces is often distributed, but accountability for spoofing outcomes is still central. That creates a classic governance mismatch: the team that operates the subdomain may not control the parent domain policy. Practitioners should map operational ownership to DNS policy ownership, then validate that reporting and enforcement follow the same boundary.

Non-existent subdomain abuse is a policy ambiguity issue as much as a phishing issue. The np tag formalises a pattern defenders already face: attackers create plausible-looking hostnames under trusted domains to bypass user and receiver assumptions. The named concept here is boundary ambiguity risk, and it is what malicious subdomain abuse exploits. Practitioners should ensure their controls distinguish real delegated zones from invented ones.

Transition management matters because receiver heterogeneity is permanent, not temporary. Security teams often assume standards adoption moves cleanly from old to new, but email ecosystems rarely behave that way. Cross-version records are therefore a governance strategy, not a compatibility hack. Practitioners should plan for mixed interpretation whenever protocol updates alter how policy is discovered or enforced.

Testing signals must be paired with monitoring or they become false reassurance. The t tag is only useful when teams know what failure looks like, who reviews the evidence and when they will move from testing to enforcement. That makes DMARC maturity partly an operational accountability question. Practitioners should tie testing states to explicit exit criteria and reporting ownership.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Boundary ambiguity is the real control gap in DMARC transition work. When delegated domains, inherited policies and non-existent subdomain handling are all implicit, receiver behaviour becomes harder to predict and harder to govern. The operational answer is to make policy boundaries visible in DNS and to keep them visible until receiver adoption settles.

DMARC maturity now depends on interpretability, not just enforcement strength. Security teams should expect mixed receiver behaviour whenever a protocol update changes how policy is read, and they should manage that heterogeneity as a standing programme risk. Explicit boundary tags, aligned reporting ownership and monitored testing states are the practical control levers.

Policy precision matters as much as message authentication. In environments with delegated email namespaces, the control problem shifts from proving sender legitimacy to proving that the record itself can be read consistently across systems. Teams that treat DMARC as a governance layer are better positioned to reduce spoofing ambiguity and to support incident response when abuse occurs.

For practitioners

• Define delegated namespace ownership explicitly Map which teams control apex domains, delegated subdomains and reporting mailboxes so DMARC policy follows the operating boundary, not just the DNS tree.
• Publish cross-version DMARC records during transition Keep legacy-relevant tags such as adkim, aspf, pct, rf and ri explicit while adding RFC 9989 tags so old and new receivers can interpret the record consistently.
• Use np only for genuine subdomain abuse cases Set non-existent subdomain policy where inventing hostnames below your organisational domain is a real attack path, and validate that it does not interfere with legitimate delegated names.
• Treat t=y as a monitored testing state Attach clear monitoring, failure review and exit criteria to testing mode so policy experiments do not become indefinite soft enforcement.
• Validate reporting and alignment before tightening enforcement Confirm that rua and ruf destinations, SPF alignment and DKIM alignment all support the intended organisational domain boundary before moving to stricter handling.

Key takeaways

• DMARC RFC 9989 is less about adding tags for their own sake and more about making policy intent readable across mixed receiver behaviour.
• The main governance risk is ambiguity in delegated namespaces and non-existent subdomain handling, where inherited assumptions can produce inconsistent outcomes.
• Security teams should keep cross-version records, make boundaries explicit and tie testing states to monitored exit criteria before tightening enforcement.

Key terms

• DMARC: DMARC is an email authentication policy mechanism that uses DNS-published records to tell receiving mail systems how to handle messages that fail alignment checks. It helps reduce impersonation risk, but it only works when the published policy is accurate, current, and governed as part of the domain's security state.
• Organizational Domain: The Organizational Domain is the domain boundary used to determine which DMARC policy applies. Under newer discovery logic, the selected boundary can differ from older assumptions, which means alignment and policy application must be tested against real sender paths rather than assumed from DNS structure alone.
• Non-Existent Subdomain Abuse: Non-existent subdomain abuse is a spoofing pattern where an attacker invents a host below a legitimate domain and relies on its apparent legitimacy. DMARC's handling of these names matters because receivers may treat them differently depending on policy clarity and namespace interpretation.
• Cross-Version DMARC Record: A cross-version DMARC record includes both legacy and newer policy tags so receivers using different specification versions can still interpret the same intended outcome. This is a transition control, not a permanent design, and it reduces ambiguity while the ecosystem moves between standards generations.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management for practitioners who need stronger control over identity-driven security risk. It helps security and identity teams connect governance decisions to operational enforcement across modern programmes.