Notifications
Clear all
Topic starter
14/07/2026 4:23 pm
TL;DR: DMARC RFC 9989 refines organizational domain discovery, alignment logic, indirect mail handling, and reporting consistency, which should make enforcement outcomes more predictable across mailbox providers, according to Proofpoint. For IAM and security teams, the shift matters because visibility into every sender, subdomain policy, and third-party mail flow becomes the difference between workable enforcement and hidden impersonation risk.
NHIMG editorial — based on content published by Proofpoint: DMARC RFC 9989, aggregate reporting, and forensic reporting updates
Questions worth separating out
A: Start by inventorying every authorised sender, including marketing, support, and transactional platforms, then validate SPF and DKIM for each one.
Q: Why do indirect mail flows complicate DMARC enforcement?
A: Forwarding and list services can alter the message path in ways that disrupt SPF or DKIM even when the original sender was legitimate.
Q: What do security teams get wrong about SPF, DKIM, and DMARC?
A: They often deploy them as isolated email settings instead of treating them as enforcement controls for domain identity.
Practitioner guidance
- Revalidate organizational and subdomain policy boundaries Map every published DMARC policy to its parent organizational domain and test whether subdomains inherit the intended enforcement state under RFC 9989 logic.
- Inventory every legitimate sender and relay path Build a current inventory of SaaS mailers, forwarding services, mailing lists, and shadow IT senders, then verify SPF and DKIM alignment for each one.
- Test reject scenarios before switching enforcement Simulate quarantine and reject outcomes across major mailbox providers so teams can see which senders fail only because of inconsistent receiver behavior or intermediary handling.
What's in the full article
Proofpoint's full article covers the operational detail this post intentionally leaves for the source:
- Side-by-side explanation of RFC 9989, RFC 9990, and RFC 9991 changes for practitioners already operating DMARC.
- Proofpoint's guidance on moving from p=none to quarantine and reject with staged validation.
- Operational detail on sender discovery, third-party mailer onboarding, and report normalisation.
- Practical handling considerations for forwarding, mailing lists, and internationalized domains.
👉 Read Proofpoint's analysis of DMARC RFC 9989 and reporting updates →
DMARC RFC 9989 and sender enforcement: what changes for teams?
Explore further
14/07/2026 4:31 pm
DMARC is becoming a governance control, not just an anti-phishing control. RFC 9989 reduces ambiguity in how receivers interpret policy, but the real effect is to make sender ownership and policy intent harder to hide. That matters because email trust depends on knowing which systems can speak for a domain and whether those systems are still under control. For practitioners, the issue is no longer whether DMARC exists, but whether its enforcement model matches the actual mail estate.
A question worth separating out:
Q: Who is accountable when subdomain policy inheritance fails?
A: Accountability sits with the domain owners and the teams that control sender onboarding, policy publication, and receiver testing. DMARC failures are often framed as protocol problems, but inheritance drift usually reflects governance gaps in domain administration, third-party sender management, and change control. Those are ownership questions, not just technical ones.
👉 Read our full editorial: DMARC RFC 9989 tightens policy enforcement and reporting
