Topic starter
14/07/2026 4:27 pm
TL;DR: DMARC RFC 9989 shifts enforcement from a simple DNS change to a readiness problem: teams must inventory legitimate senders, keep SPF current, DKIM-sign where possible, and validate policy discovery and reporting before moving to p=reject, according to Proofpoint. The operational lesson is that authentication, visibility, and receiver-side context now matter as much as policy publication.
Editorial analysis by NHI Mgmt Group, based on content published by Proofpoint: “DMARC RFC 9989 Part 3: Prepare for Enforcement”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/07/2026 4:34 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: DMARC RFC 9989 enforcement starts with sender readiness