DMARC RFC 9989 tightens policy enforcement and reporting

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Proofpoint's blog post: DMARC RFC 9989 tightens how receivers interpret sender identity, organisational domains, alignment, and reporting so enforcement becomes more predictable.

Why it matters: For IAM, NHI, and email security teams, the change raises the value of complete sender inventory, aligned authentication, and report-driven governance across all domains and third-party mail flows.

Context

DMARC is an email authentication control that tries to prove a sender is authorised to use a domain. RFC 9989 tightens how organisational domains, subdomains, alignment, and intermediate delivery paths are interpreted, which matters because inconsistent receiver behaviour has long created gaps between policy on paper and enforcement in practice.

The governance problem is visibility and consistency, not just spoofing. If a domain owner cannot inventory every legitimate sender, including third-party services and forwarded mail, then moving from policy monitoring to reject becomes unreliable. For organisations running multiple mail sources, that is a sender identity problem as much as an email security one.

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 does stricter DMARC interpretation matter for email security governance?

A: Because it removes ambiguity that has historically hidden weak policy design. When receiver behaviour becomes more consistent, gaps in organisational domain discovery, alignment, and forwarding handling stop being absorbed by provider differences and start surfacing as governance failures that teams have to own.

Q: Where do teams most often misjudge DMARC policy scope?

A: They usually underestimate subdomain inheritance, indirect mail flows, and third-party sending services. Those are the places where policy looks complete on paper but breaks in practice because the organisation has not validated who is actually sending, how alignment is evaluated, or whether intermediaries preserve authentication.

Q: How should organisations decide when DMARC is ready for reject?

A: Reject is appropriate only when sender inventory is complete, alignment is stable across direct and indirect flows, and reporting shows that authorised mail survives consistent enforcement. If any of those controls are missing, reject turns from a protection into an availability risk.

Technical breakdown

Organisational domain discovery now matters more

DMARC enforcement depends on receivers deciding which organisational domain a message belongs to before they apply policy. RFC 9989 standardises that discovery process so interpretation is less dependent on provider-specific lookup behaviour. That matters because ambiguous domain relationships can let subdomains inherit or bypass policy in inconsistent ways, especially when enterprise mail estates use multiple brands, delegated senders, or regional domains. The practical effect is that policy scope becomes a governance issue, not just a DNS record issue.

Practical implication: Review organisational domain mapping and subdomain policy inheritance before expecting reject-level DMARC to behave consistently.

Alignment and indirect mail flows are the real control boundary

SPF and DKIM alignment are the operational proof points DMARC uses to decide whether a sender is authorised. RFC 9989 sharpens how relaxed and strict alignment should be interpreted and gives clearer handling for forwarding, mailing lists, and other intermediated delivery paths. Those paths often break naive authentication assumptions because the original sender and the final receiver are separated by infrastructure the domain owner does not control. In practice, DMARC is less about a single pass or fail and more about preserving trust signals through complex delivery chains.

Practical implication: Test forwarding, mailing list, and SaaS mail paths separately from direct delivery so authentication breakage does not hide behind normal inbound success.

Reporting becomes a control, not a by-product

Aggregate and forensic reports are not just operational telemetry. They are the only scalable way to discover which systems are sending on behalf of a domain, where alignment fails, and which intermediaries distort delivery. RFC 9989 and the companion reporting updates standardise fields, structure, and interpretation so organisations can normalise data more reliably. That is especially relevant for large estates where malformed reports, inconsistent provider behaviour, and poor parsing have historically limited automation. Better reporting does not replace governance, but it does make governance enforceable.

Practical implication: Treat DMARC reporting as a discovery and validation workflow that feeds sender inventory, policy tuning, and exception management.

Threat narrative

Attacker objective: To send convincing mail under a trusted domain identity and exploit inconsistent enforcement to reach inboxes or bypass policy.

1. Entry occurs when an attacker or unauthorised sender reaches recipients through a domain that appears trusted but is not properly aligned to policy.
2. Credential access is not the central stage here, but sender control is abused when mailbox providers or intermediaries accept mail without consistent organisational domain enforcement.
3. Impact is impersonation, spoofed delivery, or policy drift that lets malicious or unmanaged senders bypass the domain owner’s intended controls.

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.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

DMARC RFC 9989 turns sender identity governance into a discovery problem. The decisive issue is no longer whether a policy exists, but whether the organisation can accurately enumerate every authorised sender and every domain relationship that policy must cover. That shifts the control conversation from simple domain protection to identity inventory across mail systems, third-party services, and delegated infrastructure. Practitioners should treat sender discovery as a prerequisite for enforcement, not a side task.

The standards update exposes hidden policy inheritance debt. Many environments have tolerated vague organisational-domain handling, uneven subdomain policy design, and provider-specific behaviour because the gaps were masked by inconsistent enforcement. RFC 9989 reduces that ambiguity, which means weak configurations are more likely to fail visibly. The named concept here is sender inheritance debt: the accumulation of unresolved subdomain and delegated-sender assumptions that only become obvious when policy is applied consistently. Teams should resolve those assumptions before the standard forces the issue.

Email authentication is becoming a governance control for the whole sending estate. The practical boundary now includes forwarding services, mailing lists, SaaS senders, and regional domains, all of which can break or weaken authentication in different ways. That makes DMARC closer to an enterprise identity problem than a narrow mail gateway setting, especially where third-party senders are part of the business model. Practitioners should expect audit pressure to move from isolated policy review toward full estate accountability.

RFC 9989 validates the shift from monitoring to enforceable trust. The standard does not create the need for visibility, but it makes weak visibility much harder to ignore. Organisations that have relied on partial coverage or receiver inconsistency to delay reject-level policy will find that tolerance shrinking. For IAM and security leaders, the consequence is clear: sender governance now has to be managed like any other identity lifecycle, with inventory, exception handling, and retirement of unmanaged sources.

DMARC reporting is now part of the operating model for impersonation defence. Standardised aggregate and forensic reporting matters because control efficacy depends on seeing where alignment breaks and which senders are actually in use. That aligns with NIST CSF governance and detection expectations, and with email identity controls in broader identity security programmes. The practitioner conclusion is to connect reporting, policy, and inventory in one operational loop rather than treating them as separate tasks.

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: IAM and Identity Provider Buyer's Guide

What this signals

Sender inheritance debt: many organisations have accumulated hidden assumptions about subdomain policy and delegated mail flows, and RFC 9989 makes those assumptions harder to ignore. For practitioners, the immediate task is to convert DMARC from a mail-team setting into an identity governance problem with named owners, validated sender sources, and exception retirement.

The next operational pressure point is reporting quality. If aggregate and forensic data cannot be normalised cleanly, teams will keep operating with partial sender visibility and delayed remediation, which is exactly the condition that undermines reject-level policy.

For practitioners

• Rebuild sender inventory across all domains Identify every system that sends mail on behalf of the organisation, including SaaS platforms, forwarding services, and regional business units, then classify which ones are authorised, unmanaged, or unknown.
• Revalidate organisational and subdomain policy inheritance Check where subdomains inherit DMARC policy today, where they should not, and where receiver interpretation may change under stricter organisational domain discovery.
• Test indirect mail flows separately Run validation for forwarding, mailing lists, and intermediary delivery paths so SPF and DKIM breakage is identified before enforcement is raised to quarantine or reject.
• Normalise DMARC reports into a single operational view Use aggregate and forensic reports to reconcile provider differences, track unauthorised senders, and create a repeatable workflow for remediation and exception handling.
• Move policy decisions from monitoring to enforcement Set a staged path from p=none to quarantine to reject only after alignment, reporting, and sender inventory show that legitimate mail will survive consistent enforcement.

Key takeaways

• DMARC RFC 9989 reduces ambiguity in how receivers discover organisational domains, apply alignment, and interpret intermediary delivery paths.
• The practical risk is not only spoofing, but hidden policy gaps across subdomains, third-party senders, and forwarded mail.
• Teams that want reliable reject-level enforcement need complete sender inventory, validated alignment, and reporting that can support ongoing governance.

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.
• Alignment: Alignment is the condition in which business functions, messages, and decisions support the same corporate strategy. In cybersecurity organisations, alignment helps sales, marketing, and customer success work as one motion, reducing mixed signals and ensuring that execution supports long-term goals rather than local preferences.
• Aggregate Report: A DMARC aggregate report is a summary of email authentication results sent by mailbox providers. It shows which sources attempted to send mail, whether authentication passed, and where alignment problems exist. Teams use it to discover legitimate senders, spot unknown infrastructure, and decide when stronger policy is safe.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives identity and security practitioners a structured way to manage credentials, trust boundaries, and lifecycle controls across modern environments.