Notifications
Clear all
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.
NHIMG editorial — based on content published by Proofpoint: DMARC RFC 9989 enforcement readiness and sender validation
Questions worth separating out
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.
Q: Why do SPF, DKIM, and DMARC need to be managed together?
A: They solve different parts of the same trust problem.
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 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.
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
👉 Read Proofpoint's guidance on DMARC RFC 9989 enforcement readiness →
DMARC RFC 9989 readiness: are your controls keeping up?
Explore further
14/07/2026 4:34 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: DMARC RFC 9989 enforcement starts with sender readiness
