DMARC RFC 9989 enforcement starts with sender readiness

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Proofpoint's blog post: DMARC RFC 9989 enforcement is a readiness problem, not just a policy change, because sender inventory, SPF hygiene, DKIM alignment, and policy discovery all affect whether legitimate mail passes.

Why it matters: For IAM and email security teams, the change matters because email identity controls now depend on accurate sender governance across systems, third parties, and delegated domains.

Context

DMARC only works cleanly when the sending ecosystem is known, authorised, and continuously reviewed. RFC 9989 raises the stakes because alignment and policy discovery can change depending on the Organizational Domain a receiver resolves, which turns email authentication into a governance and lifecycle issue rather than a single DNS update.

For identity and messaging teams, the important shift is that legitimacy is now evaluated across sender inventory, SPF authorization, DKIM signing, and receiver-side policy interpretation. That makes this topic relevant to IAM-style governance even though the control plane sits in email infrastructure, because the real risk is unmanaged identity authority over who can send as the domain.

Key questions

Q: What breaks when DMARC enforcement is turned on before sender inventories are complete?

A: Legitimate business mail can be quarantined or rejected because SPF and DKIM only work when every approved sender is accounted for. The failure mode is not the protocol itself, but incomplete ownership of the systems that send mail from the domain.

Q: Why do DKIM and SPF both matter when moving to p=reject?

A: SPF helps validate sending hosts, but it is fragile when mail is forwarded or relayed. DKIM provides a cryptographic signature that survives more of the delivery path, so the two controls complement each other. When p=reject is the target, relying on SPF alone leaves legitimate traffic exposed to avoidable failure.

Q: How do security teams know whether DMARC enforcement is actually working?

A: Look for fewer authentication failures from legitimate senders, stable alignment for critical mail flows, and reporting that clearly shows why a message passed or failed. If failures cannot be explained quickly, the programme is not ready for stricter enforcement. Working DMARC is visible, reproducible, and backed by clean sender inventory.

Q: Should receiver-side context override a published reject policy?

A: Yes, when the message handling decision depends on broader anti-abuse knowledge, local policy, and business impact. RFC 9989 explicitly leaves final handling to the receiver, so a published reject policy should guide decisions rather than force blind rejection of every failed message.

Technical breakdown

Why RFC 9989 changes DMARC enforcement logic

RFC 9989 does not remove DMARC’s core purpose, but it changes how receivers discover the relevant Organizational Domain and which policy record they apply. That means the same message can be evaluated against different boundaries than teams assumed under RFC 7489. In practice, SPF alignment, DKIM alignment, and policy tags such as p, sp, and np can produce different results depending on delegation and subdomain structure. The technical issue is not just whether a message authenticates, but whether the receiver resolves the right control point before deciding what to do with it.

Practical implication: Map every domain boundary and delegation path before tightening enforcement.

Why SPF alone is not enough at p=reject

SPF answers whether a message came from an authorised sending host, but it does not always survive forwarding, relaying, or intermediary infrastructure changes. That is why RFC 9989 reinforces DKIM signing for domains moving toward p=reject. DKIM binds the message to the domain’s cryptographic identity, so a legitimate message can remain verifiable even when the envelope path changes. In operational terms, teams that rely only on SPF create a fragile authentication model that can break for valid business mail while still leaving room for abuse if authorization is too broad.

Practical implication: Treat DKIM coverage as mandatory for critical senders before enforcing reject.

How receiver-side policy discovery and reporting affect visibility

RFC 9989 makes policy discovery more precise, but that precision also introduces new failure modes. If the Organizational Domain or policy record resolved by the receiver differs from the sender team’s expectation, aggregate reporting destinations and failure interpretation can shift too. That means teams may lose visibility into why mail failed, or into which record actually drove the result. The governance problem here is not only authentication failure, but opaque failure context. Without clear reporting, organisations cannot distinguish legitimate sender misconfiguration from abuse or from boundary mismatch.

Practical implication: Validate report destinations and failure interpretation under RFC 9989 before changing policy.

Threat narrative

Attacker objective: The objective is to impersonate trusted domain traffic well enough to deliver abuse or to undermine legitimate mail delivery and trust.

1. Entry occurs when an attacker exploits domain spoofing or impersonation opportunities created by weak sender governance and incomplete authentication coverage.
2. Credential access is not the primary issue here; the attacker instead abuses trust in the domain identity and any misalignment between SPF, DKIM, and the resolved policy boundary.
3. Impact appears when fraudulent mail is accepted as legitimate or when legitimate mail is blocked because the organisation has not validated receiver-side RFC 9989 behaviour.

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

RFC 9989 turns DMARC into a governance problem, not a policy toggle. The core issue is that sender legitimacy now depends on continuously current inventory, authorisation, and cryptographic signing. If teams treat DMARC as a one-time reject decision, they will miss the lifecycle work needed to keep legitimate senders aligned as systems change. The practitioner conclusion is to govern sender identity like any other access path.

DMARC failure analysis now has a boundary-discovery problem. Under RFC 9989, the receiver may resolve a different Organizational Domain or policy record than the sender expected, which means the control failure may sit in discovery rather than authentication. That is a useful named concept: DMARC boundary mismatch. The practical implication is that enforcement readiness must include testing how receivers resolve the policy, not just checking whether a record exists.

SPF hygiene without DKIM coverage leaves an avoidable enforcement gap. SPF remains necessary, but it is no longer a safe sole control for domains that intend to move to reject. Forwarders, relays, and delegated senders can break SPF even when the message is legitimate, so DKIM becomes the stronger continuity control. The practitioner conclusion is simple: if the message flow matters, sign it and track the alignment path end to end.

Receiver context should shape inbound handling of DMARC failures. RFC 9989 reinforces that domain policy is not the only decision signal. Local policy, sender reputation, and anti-abuse context still matter, which means mail security teams should avoid treating a published reject policy as a blind automation rule. The practical implication is to preserve human-visible decisioning for ambiguous failures until the environment is well understood.

Service-account style governance thinking belongs in email identity too. The article’s strongest lesson is that unmanaged senders behave like unmanaged identities: they accumulate over time, outlive their original purpose, and create trust that no one can fully explain later. That makes DMARC enforcement part of identity lifecycle management, not just messaging hygiene. The practitioner conclusion is to inventory, validate, and retire senders on a continuous cadence.

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

DMARC boundary mismatch: the most important operational risk in RFC 9989 is that sender teams and receivers may not resolve the same policy boundary. That makes policy discovery and reporting validation a prerequisite for enforcement, not a post-change troubleshooting step.

The practical implication for identity and messaging teams is to manage email senders as a living identity estate. Systems, third parties, and application senders should be inventoried, authorised, signed, and retired on a continuous cadence, otherwise DMARC will expose governance debt rather than eliminate it.

For practitioners

• Inventory every legitimate sender Build and maintain a current list of all systems, applications, and third parties that send mail for your domains, then verify which ones must be authorised and aligned.
• Refresh SPF authorisation regularly Review every include, remove vendors that no longer send mail, and avoid overly broad authorisation that could let abusive traffic pass as legitimate.
• Close DKIM gaps before reject Prioritise high-volume and business-critical senders that do not yet sign with aligned DKIM, especially where forwarding or relaying can break SPF.
• Test policy discovery and report paths Validate which Organizational Domain and policy record receivers resolve, then confirm that aggregate and forensic report destinations are still reachable and expected.
• Use receiver context for inbound decisions Treat published policy as one signal among others, and combine DMARC results with local risk analysis, sender reputation, and anti-abuse controls.

Key takeaways

• DMARC RFC 9989 makes sender readiness the real gating factor for enforcement, because policy alone does not guarantee that legitimate mail will align and pass.
• The biggest operational risk is boundary mismatch, where receivers resolve a different Organizational Domain or policy record than the sender expected.
• Teams should validate sender inventory, SPF authorisation, DKIM alignment, and reporting paths before moving domains to stricter handling.

Key terms

• DMARC Boundary Mismatch: A mismatch between the domain boundary a sender expects and the one a receiver actually resolves when evaluating DMARC. In RFC 9989 environments, that mismatch can change which policy applies, whether identifiers align, and how failures are reported, creating a governance problem rather than a simple record problem.
• 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.
• SPF and DKIM Alignment: SPF and DKIM alignment is the condition that the authenticated domain matches the domain used in the message that DMARC evaluates. When the organizational boundary changes, a message that previously aligned may no longer satisfy the chosen policy boundary.
• Sender Inventory: A sender inventory is the complete list of services, applications, and systems authorized to send email for a domain. It is the governance baseline for DMARC because enforcement is only safe when every legitimate sender has been identified, authenticated, and mapped to an owner.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management in a way that helps practitioners connect identity controls to operational risk. It is useful for teams that need to govern access paths, credentials, and delegated authority across modern environments.