DMARC RFC 9989 enforcement starts with sender readiness

At a glance

What this is: RFC 9989 makes DMARC enforcement a sender-readiness and policy-discovery problem, not just a DNS update.

Why it matters: IAM and security teams need to know which systems can send for the domain, how they authenticate, and whether enforcement decisions will still preserve legitimate mail delivery and visibility.

👉 Read Proofpoint's guidance on DMARC RFC 9989 enforcement readiness

Context

DMARC works only when the organisation knows every legitimate sender, how each sender authenticates, and how policy discovery behaves under the chosen domain boundary. RFC 9989 increases the governance burden because alignment and reporting can change when the evaluated Organizational Domain differs from older assumptions, which makes domain abuse prevention depend on identity and access control over mail-sending systems.

For identity and access teams, the real issue is not just mail filtering. It is lifecycle control over the systems, applications, and third parties that are authorized to send as the organisation, plus the visibility needed to detect when that authorization drifts. That is why DMARC readiness now sits alongside broader identity governance rather than being treated as a standalone email task.

Key questions

Q: What breaks when DMARC enforcement is moved to p=reject too early?

A: The usual failure is that legitimate mail starts failing because sender inventories are incomplete, SPF records are stale, or aligned DKIM is missing. That creates delivery disruption and investigation noise, especially for forwarding, relay, and third-party systems. Teams should not move to p=reject until they can prove which senders are authorized and how each one authenticates.

Q: Why do SPF, DKIM, and DMARC need to be managed together?

A: They solve different parts of the same trust problem. SPF limits which systems may send, DKIM proves message integrity, and DMARC tells recipients how to act when authentication fails. If only one is in place, the sender can still be spoofed, misrouted, or treated as untrusted by mailbox providers.

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: Who is accountable when a domain is abused for impersonation mail?

A: Accountability sits with the teams that own sender authorization, policy discovery, and mail delivery controls, not just the email security toolset. If a domain can be abused, someone failed to maintain the lifecycle of authorized senders, keep authentication current, or validate enforcement assumptions. That makes DMARC a governance issue as well as a technical one.

Technical breakdown

Policy discovery and Organizational Domain selection in RFC 9989

RFC 9989 changes how receivers determine the policy boundary they apply, including which Organizational Domain is selected and where policy is discovered. That matters because a message that aligned under older assumptions may fail under the newer selection logic if the boundary shifts, if the record lives in a different DNS location, or if subdomain handling changes through the p, sp, or np tags. The technical point is that DMARC is not one lookup, it is a decision tree with boundary resolution before enforcement. Practical implication: validate policy discovery against real sending paths before changing enforcement.

Practical implication: Validate policy discovery against real sending paths before changing enforcement.

Why SPF alone is not enough at p=reject

SPF proves that a message came from an authorized sending IP, but it does not survive every legitimate mail flow. Forwarding, relaying, and infrastructure changes can break SPF even when the original sender is legitimate, which is why RFC 9989 strongly reinforces aligned DKIM for domains moving to p=reject. In practice, SPF should be treated as one signal in a broader authentication model, not the only control carrying enforcement. Practical implication: require DKIM alignment for critical senders before tightening DMARC policy.

Practical implication: Require DKIM alignment for critical senders before tightening DMARC policy.

Receiver-side enforcement uses local policy and abuse context

RFC 9989 is explicit that the mail receiver retains final handling discretion. That means a receiver may quarantine, reject, or accept a message based on local policy, sender reputation, user risk, and other anti-abuse controls, even when DMARC passes or fails in a particular way. This is operationally important because DMARC is a strong signal, not a complete trust decision. Practical implication: build inbound enforcement playbooks that combine DMARC with reputation, content, and business-context checks.

Practical implication: Build inbound enforcement playbooks that combine DMARC with reputation, content, and business-context checks.

Threat narrative

Attacker objective: The attacker wants to abuse a trusted domain boundary to deliver impersonation mail that users and filters treat as legitimate.

1. Entry begins when attackers exploit weak or stale domain-sending authorization to send abusive mail that appears to belong to a trusted organisation.
2. Escalation occurs when receivers or downstream users rely on outdated policy assumptions, allowing spoofed or misaligned mail to retain credibility.
3. Impact follows in the form of phishing, impersonation, and domain abuse that can bypass user suspicion and degrade trust in legitimate mail.

NHI Mgmt Group analysis

DMARC readiness has become an identity governance problem. The article shows that enforcement depends on knowing which systems, applications, and third parties are authorized to send on behalf of a domain. That is the same governance question IAM teams face with any privileged access path, only here the asset is sender authority rather than a console login. The practical conclusion is that email authentication is now part of access governance, not a separate hygiene exercise.

RFC 9989 exposes a policy discovery gap that many teams will miss. The standard makes Organizational Domain selection and record resolution part of the control path, which means old assumptions about where policy lives may no longer hold. This creates a governance gap between intended policy and applied policy, especially in delegated or nested domain structures. Practitioners should treat policy discovery as a control dependency and validate it continuously.

DKIM alignment is the real enforcement hinge for legitimate traffic. The article reinforces that SPF-only thinking breaks down once organisations move toward p=reject, because legitimate flows can fail on forwarding or relay paths. That is a familiar identity pattern: one control looks sufficient until operating reality introduces path variance. Teams should therefore frame DKIM not as an optional enhancement but as the durability layer for authenticated sender identity.

Receiver discretion means DMARC is never a single-point decision rule. RFC 9989 makes clear that inbound handling must blend DMARC with local policy and broader anti-abuse context. That matters because many organisations over-interpret domain policies as commands rather than signals. The governance implication is that secure mail handling requires context-aware decisioning, not policy literalism.

Domain abuse prevention now depends on lifecycle control over sender relationships. The article’s recurring themes are sender inventory, ongoing SPF review, report visibility, and remediation of broken DKIM. That is a classic lifecycle pattern: authorization is created, modified, and eventually needs revocation or correction. Practitioners should manage mail-sending relationships with the same discipline they apply to privileged accounts and service identities.

What this signals

Sender authority is becoming a first-class identity control for email. As organisations tighten DMARC, they will need the same lifecycle discipline they use for privileged access: inventory, authorization, review, and revocation. That makes mail-sending relationships a governance object, not an IT side task.

The operational risk is not just spoofing, but policy drift between what administrators believe is enforced and what receivers actually apply. Teams should test the boundary behavior of DMARC records the same way they validate access paths elsewhere, because a misplaced assumption about the Organizational Domain can create blind spots in enforcement.

Practitioners should expect more reliance on context-aware receiver decisions and less confidence in policy literalism. That means mail security programmes will need stronger reporting, faster remediation workflows, and a tighter link between identity governance and domain authentication operations.

For practitioners

• Inventory every domain sender relationship Document all systems, applications, and third parties that send mail for each domain, then map each one to SPF authorization, DKIM alignment, and the policy path it should follow.
• Review SPF records on a fixed cadence Remove obsolete includes, confirm each authorization still maps to an active sender, and avoid broad allowances that outlive the business relationship they were created for.
• Require DKIM signing for critical senders Prioritise high-volume and business-critical systems that cannot survive SPF breakage from forwarding or relay, and make aligned DKIM the default condition before p=reject.
• Test policy discovery before enforcing Validate the Organizational Domain selected by receivers, the record location they resolve, and whether p, sp, or np will change handling for existing and non-existent subdomains.
• Build context-aware inbound handling Use DMARC together with sender reputation, user risk, and anti-abuse signals so receivers do not treat published policy as the only decision input.

Key takeaways

• RFC 9989 turns DMARC into a readiness exercise, because sender authorization, policy discovery, and reporting all affect whether enforcement is safe.
• SPF alone is not durable enough for strict enforcement, so aligned DKIM becomes the practical control that preserves legitimate mail through forwarding and relay paths.
• The governance task is to manage sender authority across its full lifecycle, from authorization to review to removal, before attackers exploit stale trust.

Key terms

• DMARC Readiness: DMARC readiness is the state where a domain can move to stricter enforcement without breaking legitimate mail flows. It depends on knowing all authorized senders, keeping SPF accurate, ensuring aligned DKIM where needed, and having reporting that reveals failures fast enough to fix them.
• 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.
• Aligned Dkim: Aligned DKIM means the message is signed and the signing domain matches the domain being authenticated under DMARC policy rules. It is the control that helps legitimate mail survive forwarding and relay scenarios where SPF may fail, especially when domains move toward reject policies.
• Sender Authorization Lifecycle: Sender authorization lifecycle is the full process of approving, reviewing, changing, and removing systems or third parties that can send mail for a domain. Treating this lifecycle as governed access helps prevent stale trust from becoming a spoofing or impersonation path.

What's in the full article

Proofpoint's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step sender inventory and remediation workflow for legitimate mail streams
• Detailed discussion of RFC 9989 policy discovery, including Organizational Domain and tag handling
• Practical guidance for aligning SPF and DKIM before moving domains to p=reject
• Receiver-side enforcement considerations for blending DMARC with local anti-abuse policy

👉 Proofpoint's full post covers sender inventory, policy discovery, and inbound enforcement details

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle controls that underpin durable access governance. It helps practitioners connect sender authority, privileged access, and authentication hygiene to broader identity programmes.