Topic starter
14/07/2026 4:21 pm
TL;DR: DMARC RFC 9989 adds tags for non-existent subdomains, delegated namespace boundaries, and testing state, while leaving receivers to adopt the new model at different speeds, according to Proofpoint. That makes explicit cross-version records, not minimalist records, the practical control for predictable email authentication outcomes.
Editorial analysis by NHI Mgmt Group, based on content published by Proofpoint: “DMARC RFC 9989 Part 2: How to Use the New Tags”.
Key questions
Q: What breaks when DMARC records do not express namespace boundaries clearly?
A: Receivers can interpret the same policy differently, especially in delegated or nested domains.
Q: Why do non-existent subdomains create phishing risk in DMARC?
A: Because attackers can invent hostnames below a trusted organisational domain and rely on receivers or users to treat them as legitimate.
Q: How should teams manage DMARC during receiver transition?
A: Keep a cross-version record with explicit legacy and RFC 9989 tags until adoption is stable across the receiving ecosystem.
Practitioner guidance
- Define delegated namespace ownership explicitly Map which teams control apex domains, delegated subdomains and reporting mailboxes so DMARC policy follows the operating boundary, not just the DNS tree.
- Publish cross-version DMARC records during transition Keep legacy-relevant tags such as adkim, aspf, pct, rf and ri explicit while adding RFC 9989 tags so old and new receivers can interpret the record consistently.
- Use np only for genuine subdomain abuse cases Set non-existent subdomain policy where inventing hostnames below your organisational domain is a real attack path, and validate that it does not interfere with legitimate delegated names.
Bottom line: DMARC RFC 9989 is less about adding tags for their own sake and more about making policy intent readable across mixed receiver behaviour.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 hours ago by NHI Mgmt Group
14/07/2026 4:29 pm
Policy precision has become a control plane problem, not a formatting preference. DMARC records now need to communicate intent across mixed receiver populations, delegated namespaces and transition states. When the same record can be interpreted differently, governance breaks before enforcement does. Practitioners should treat explicit policy expression as part of mail security architecture, not an administrative detail.
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: What should security teams do when DMARC testing mode is in use?
A: Use testing only with active monitoring, defined failure review and a clear exit plan. Testing should show which senders fail, whether alignment is working and whether the failures are legitimate mail or abuse, otherwise it becomes a permanent gray zone.
👉 Read our full editorial: DMARC RFC 9989 raises the bar for domain policy precision
This post was modified 2 hours ago by NHI Mgmt Group