DMARC RFC 9989 raises the bar for domain policy precision

At a glance

What this is: This is a technical analysis of DMARC RFC 9989 and how its new tags change policy expression, boundary handling, and transition behavior across receivers.

Why it matters: It matters because email identity controls only work when domain owners can express intent clearly across mixed receiver behavior, which affects spoofing resistance, reporting, and enforcement planning.

👉 Read Proofpoint's technical guide to DMARC RFC 9989 transition controls

Context

DMARC policy only becomes reliable when receivers interpret the same namespace and enforcement intent in the same way. RFC 9989 tries to reduce ambiguity by adding clearer signals for non-existent subdomains, delegated domain boundaries, and testing state, which is directly relevant to email identity governance.

For IAM, PAM, and broader identity programmes, the connection is not just email hygiene. DMARC remains an identity control for domain trust, sender validation, and fraud resistance, so the transition to RFC 9989 affects how teams manage authentication policy, reporting ownership, and enforcement across distributed business units.

Key questions

Q: How should security teams manage DMARC changes when receivers adopt new policy semantics at different speeds?

A: Publish records that remain explicit under both old and new DMARC behavior, then test against the receiver mix you actually use. The goal is to avoid hidden interpretation differences that produce inconsistent quarantine or reject outcomes. Treat receiver diversity as part of the control design, not as an edge case.

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. That creates ambiguity unless the boundary is declared clearly and the operational ownership for SPF, DKIM, and reports is aligned to it.

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. That weakens anti-spoofing controls and gives phishing campaigns more room to exploit trust in the parent domain.

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.

Technical breakdown

Cross-version DMARC records during receiver transition

RFC 9989 does not create a clean cutover because receivers will adopt the updated semantics at different rates. That means a record needs to remain intelligible to both RFC 7489-era and RFC 9989-capable receivers. The operational pattern is to publish explicit legacy-relevant tags alongside the new ones, so receivers can resolve policy intent without guessing. This is less about syntax preference and more about avoiding inconsistent policy interpretation during a transition window where some receivers will still rely on older behavior.

Practical implication: Keep legacy and updated tags explicit in the same DMARC record until receiver behavior is stable across your ecosystem.

How the psd tag defines delegated domain boundaries

The psd tag replaces reliance on the Public Suffix List for boundary signaling in DNS. In delegated environments, that matters because a team operating a sub-namespace may need its own organizational boundary, reporting path, and policy authority without waiting on apex-domain changes. The tag lets receivers determine which node should behave as the Organizational Domain. That makes boundary definition an explicit policy decision rather than an inferred one, which is especially useful where brand, region, or business-unit ownership is distributed.

Practical implication: Use psd only where namespace ownership is intentionally delegated and validate SPF, DKIM, and reporting against that boundary.

Non-existent subdomain handling and the np tag

The np tag addresses a common abuse pattern where attackers send mail from a subdomain that appears plausible but does not actually exist in DNS. Under older behavior, those cases could fall back into broader subdomain policy handling, which leaves room for ambiguity. RFC 9989 lets domain owners define how receivers should treat failures from these non-existent names directly. That closes a control gap for phishing and impersonation campaigns that rely on fake but believable subdomains to inherit trust from the parent domain.

Practical implication: Set np deliberately for domains with valuable brand trust and test how receivers handle spoofed subdomains before enforcement.

Threat narrative

Attacker objective: The attacker wants to send trusted-looking mail from believable domain variants and exploit policy ambiguity to improve delivery or bypass defences.

1. Entry occurs through lookalike or non-existent subdomains that borrow trust from an established organizational domain.
2. Escalation happens when receivers interpret old and new DMARC semantics differently, letting ambiguous policy outcomes persist.
3. Impact is spoofed or misclassified mail that weakens impersonation defenses and makes enforcement inconsistent across the receiver base.

NHI Mgmt Group analysis

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.

The new boundary model exposes a long-standing governance problem: receivers have been inferring organisational scope too much for themselves. The psd tag makes the namespace boundary a declared control rather than a derived assumption. That is a meaningful shift for enterprises that manage multiple brands, regions, or delegated subdomains. Practitioners should treat boundary declaration as a governance decision with reporting and ownership consequences, not a DNS formatting exercise.

Non-existent subdomain abuse is a form of identity spoofing, not just mail hygiene failure. Attackers benefit when a receiver can be nudged into treating a fake namespace as if it belonged to the legitimate domain. RFC 9989 gives defenders a way to state that those names should not inherit trust. The operational lesson is that domain trust needs explicit negative policy, not only positive authentication signals.

Testing flags only work when they are paired with accountability for remediation. The t tag helps separate validation from enforcement, but that separation can also hide stalled programmes if no one owns failure review, sender cleanup, and policy progression. Identity teams should therefore connect DMARC testing to clear remediation workflows and change control, otherwise the organisation simply codifies perpetual pilot mode.

Cross-version compatibility is now an adoption risk that identity programmes need to track like any other control drift. Mixed receiver behavior means the same policy can produce different outcomes across destinations, which affects enforcement confidence, fraud monitoring, and service desk noise. The practical conclusion is that DMARC migration needs receiver mapping, not just record editing.

What this signals

DMARC policy changes often fail not because the syntax is wrong, but because ownership and receiver behavior are not aligned across the mail ecosystem. That creates a governance problem familiar to identity teams: controls only work when the trust boundary is explicit, the reporting path is owned, and the transition plan is measurable.

Policy ambiguity debt: when mail security records carry mixed old and new semantics, organisations accumulate a hidden form of control drift. The result is inconsistent enforcement across receivers and harder fraud triage, which is why DMARC transitions should be managed as a change programme, not a one-time record update.

Identity and fraud teams should also think about namespace governance as a business process, not a DNS task. Delegated domains, sub-brands, and testing states all need named owners, documented exit criteria, and monitoring that ties policy failure back to remediation.

For practitioners

• 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. Validate the final record against representative receivers before moving toward stricter enforcement.
• 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. Confirm that SPF, DKIM, and rua routing align with that declared boundary.
• 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. Pair that with mailbox and fraud monitoring for impersonation attempts.
• Treat testing mode as a controlled change process Use t=y only when there is active monitoring, a named owner for failure analysis, and a documented exit condition to enforcement. Review alignment failures by sender, destination, and cause before changing policy.

Key takeaways

• RFC 9989 makes DMARC policy intent more explicit by adding better controls for boundaries, testing, and non-existent subdomains.
• The main risk during adoption is mixed receiver behavior, which can turn the same record into different outcomes across the mail ecosystem.
• Practitioners should treat DMARC transition as a governance process with ownership, monitoring, and enforcement milestones.

Key terms

• Organizational Domain: The organizational domain is the boundary that a domain owner wants receivers to treat as the trust root for policy evaluation. In DMARC, getting this boundary wrong changes how subdomains are interpreted, which can weaken reporting accuracy and enforcement consistency.
• Public Suffix Domain: A Public Suffix Domain is a DNS boundary that marks where one party's namespace ends and another party's begins. RFC 9989 uses this idea to make delegated boundaries explicit, so receivers can apply policy based on declared ownership rather than inferred structure.
• Non-existent Subdomain: A non-existent subdomain is a hostname beneath an organizational domain that looks legitimate but has no DNS record. Attackers use these names to mimic trusted namespaces and exploit policy ambiguity, making explicit handling a useful anti-spoofing control.
• DMARC Testing Mode: DMARC testing mode indicates that a domain owner is validating policy behavior before full enforcement. It is only useful when paired with monitoring, because the point is to learn which senders fail alignment, why they fail, and when the programme is ready to move on.

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.

👉 Proofpoint's full post covers tag behavior, namespace boundaries, and receiver transition detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management in the context of modern access controls. It helps practitioners connect identity policy design to the operational realities that shape enforcement, review, and trust.