We covered RFC 9989, the DMARCbis update, when it landed earlier this year. One of its headline fixes was the np= tag, a policy specifically for subdomains that do not exist. A DNSSEC researcher’s writeup making the rounds this week shows the fix has a gap of its own, and it opens up on exactly the domains that took the extra step of signing their DNS.
The Hole np= Was Built to Close
DMARC’s original design left an odd gap. A domain owner could publish p=reject on their organizational domain and sp=reject for its subdomains, and still have no defined policy for a subdomain that simply does not exist. Nothing was wrong with the spec, but implementations varied in how strictly they treated an invented subdomain, and attackers noticed. Spoofing something like nonexistent.yourbank.com and hoping a receiver’s fallback logic was permissive became a known evasion path, quiet enough that most domain owners never saw it in their aggregate reports because the traffic did not always show up the way real subdomain abuse would.
RFC 9989 closes that gap directly. The np= tag lets a domain owner set an explicit policy for mail claiming to be from a non-existent subdomain of the organizational domain, independent of both the root policy (p=) and the existing-subdomain policy (sp=). Set np=reject, and a message claiming to be from anything.yourbank.com, where “anything” was never provisioned, gets rejected outright, with no reliance on a receiver’s fallback behavior to save you.
Where DNSSEC Gets in the Way
The tag depends on one thing working correctly: the verifier’s ability to determine that a subdomain genuinely does not exist. That determination used to be simple. A DNS query for a name that was never provisioned returns NXDOMAIN, an unambiguous signal.
DNSSEC-signed zones increasingly do not answer that way. RFC 9824, Compact Denial of Existence in DNSSEC, defines a more efficient method for proving a name does not exist, using a synthesized NSEC record marked with the NXNAME pseudo-type instead of a traditional NXDOMAIN response. It is a legitimate, increasingly common optimization. Cloudflare and NS1 have run it since before September 2024, and Amazon Route 53 and Knot DNS’s online-signing module support it as well.
The problem is that DMARC verification logic written against RFC 9989’s definition of “non-existent” was largely written with plain NXDOMAIN in mind. A verifier that does not specifically know to check for the NXNAME bit on a compact-denial NSEC or NSEC3 response can fail to recognize that a subdomain is non-existent at all. When that happens, the np= tag simply never triggers. The message falls back to whatever sp= or p= specifies instead, which may well be more permissive, silently reopening the exact gap np= was published to close.
A survey of the top one million domains from late 2024 found that among domains with valid DNSSEC, 44% were already using NSEC-based compact denial. That is not a fringe configuration. It is the default behavior of some of the largest managed DNS platforms on the internet, deployed on a meaningful share of the domains that are, by definition, the ones taking DNS security seriously enough to have DNSSEC turned on in the first place.
The Uncomfortable Irony
The domains most likely to adopt np= early are the security-conscious ones already running a mature DMARC enforcement program, and a large share of those same domains are the ones running DNSSEC. Those are not two separate populations. They overlap heavily, which means the domains reaching for np= as their next hardening step are disproportionately likely to be on infrastructure where, without an NXNAME-aware verifier on the receiving end, the tag does not do what its documentation says.
Full support for RFC 9824 on the resolving and verifying side remains inconsistent. Some authoritative servers implement the compact “black lies” response shape without full downstream awareness propagating through every mail receiver’s DMARC implementation. Until that catches up, treating np= as a guaranteed control, rather than a best-effort one, is a mistake a domain owner will not find out about from a failed test. It will show up, if it shows up at all, as a spoofed message from a subdomain that was never supposed to exist.
What This Means for Your Program
Don’t treat np= as a substitute for a clean subdomain inventory. The tag is a backstop for the subdomains you did not provision, not a replacement for knowing which ones you did. Keep publishing explicit DMARC records, or at minimum a restrictive sp=, for the subdomain space you actually control.
Ask your DNS provider whether compact denial of existence is enabled, and ask receiving mailbox providers whether their DMARC verifiers are RFC 9824-aware. Most domain owners have never had a reason to ask either question. This is now a reason.
Do not assume a monitoring-only DMARC record tells you this is working. Aggregate reports show you what receivers evaluated and how, but a verifier that silently falls through past np= to a more permissive policy will not flag that fallback as an error anywhere you can see it.
Keep watching your aggregate reports for authentication results tied to subdomains you know do not exist. If you start seeing pass results, or results that skip np= entirely, on names you never provisioned, that is the signal this gap is live on your domain specifically, not just a theoretical one.
The Takeaway
RFC 9989 fixed a real problem. RFC 9824 fixed a different real problem. Neither working group broke the other’s specification, and neither is wrong. But the two standards were not designed against each other, and the result is a policy tag that can silently fail to apply on precisely the domains that did everything else right. DMARC has always depended on details like this lining up correctly across the whole chain, from your DNS record to the receiver’s verifier. This is one more reminder that “we published the tag” and “the tag is enforced” are two different claims, and only monitoring your actual reports tells you which one is true for your domain.
Excello Mail already supports RFC 9989, and we track exactly these kinds of gaps between DMARC and the DNS infrastructure it depends on, so a policy you believe is enforced does not turn out to be theoretical. Sign up for free to Excello Mail and get visibility into what your DMARC policy is actually doing, not just what your DNS record says it should do.