Why DMARC's new "NP" tag can fail with DNSSEC

The new np tag

In May 2026, the IETF published an updated version of the DMARC specification, consisting of three documents. RFC 9989 introduces a new DMARC record tag called np, standing for non-existent subdomain policy. In a DMARC record, it looks like this:

v=DMARC1; p=none; sp=quarantine; np=reject;

The policy specified by the p tag applies to the domain where the record is published, the sp tag applies to existing subdomains of the policy domain that do not publish their own DMARC record, while the np tag applies to non-existent subdomains. Setting different policies is helpful when you want to "block" malicious email on unused subdomains while keeping a less strict policy on the other subdomains.

Non-existent subdomains in the DNS

The DMARC RFC defines non-existent domains as follows:

For DMARC purposes, a non-existent domain is consistent with the term's meaning as described in RFC8020. That is, if the response code received for a query for a domain name is NXDOMAIN, then the domain name and any possible subdomains do not exist.

This is a common definition, nothing surprising. DNS servers typically return the NXDOMAIN response code to signal that the queried domain name and all its subdomains don't exist, meaning that they do not have any DNS record associated with them. Here's an example:

~ ❯ dig non-existent-subdomain.rai.it +noall +comments +answer
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61680
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; AUTHORITY SECTION:
cloudflare.com.         291     IN      SOA     ns3.cloudflare.com. dns.cloudflare.com. 2407081620 10000 2400 604800 300
doesnotexist.cloudflare.com. 291 IN    NSEC    \000.doesnotexist.cloudflare.com. RRSIG NSEC TYPE128
cloudflare.com.         291     IN      RRSIG   SOA 13 2 300 20260705103523 20260703083523 34505 cloudflare.com. u6pDc961FGq0rOBLW8c7D8cjPgW3keDM16d18INAPfACEF6WcyRmr9y3 EOJfv3AT9DdvHP6HZjPF9nY6v+WpIg==
doesnotexist.cloudflare.com. 291 IN    RRSIG   NSEC 13 3 300 20260705103523 20260703083523 34505 cloudflare.com. PGff3k7iGs3XPYbwYVtaRAqZO3o6Y6AK32ukfIShZU6YlHWyuEFv98Pc dJ1hzE010gOcEGz2tMgFS7uCf8sROQ==

To ensure compatibility with existing DNS software that still expects NXDOMAIN, optional features for restoring the response code were introduced, as we'll see in the next section. They are, however, optional, and the RFC explicitly mentions that if a DNS resolver doesn't implement these measures it's up to the client to read the NXNAME bit to infer domain non-existence:

In the absence of this, tools that rely on accurately determining nonexistent names will need to infer them from the presence of the NXNAME RR type in the Type Bit Maps field of the NSEC record in NODATA responses from these servers.

Let's see how these NXDOMAIN restoration methods work, what they leave out and what their real-world adoption rates are, and therefore how RFC 9824 affects DMARC.

Restoration of NXDOMAIN response code

We can split DNS queries into two categories: DNSSEC-enabled and non-DNSSEC-enabled. When you send a query from your computer, for example when using the dig command, the nslookup command or system primitives for DNS resolution, you're sending non-DNSSEC queries by default. Technically, this means that the DO flag ("DNSSEC Answer OK") in the EDNS section of the request is not set.

When a non-DNSSEC query reaches a recursive DNS resolver, different things can happen:

• The DNS resolver is not DNSSEC-aware: the authoritative nameserver will normally reply with a conventional unsigned NXDOMAIN response, and everything works normally. This scenario is however of little relevance because most modern DNS resolvers are DNSSEC-aware.
• The DNS resolver is DNSSEC-aware but not NXNAME-aware: the authoritative nameserver will reply with compact denial of existence (NOERROR and one NSEC record). The client sees no NXDOMAIN.
• The DNS resolver is DNSSEC-aware and NXNAME-aware: according to RFC 9824, the resolver "could modify the response code from NOERROR to NXDOMAIN in responses they return to downstream queriers".

According to our research (June 2026) the main commercial resolvers, such as 8.8.8.8 and 1.1.1.1, and the main open source DNS resolvers, BIND9, Unbound, PowerDNS and Knot Resolver do not restore NXDOMAIN as suggested.

A DNS query sent from a client to a resolver can have the DO bit set in the EDNS section of the request, informing the DNS resolver that the client knows how to process DNSSEC responses. According to Cloudflare Radar, these queries account for 10-12% of the total queries observed. In this case, if the authoritative nameserver responds with compact denial of existence, it will just pass the response to the client, who therefore sees no NXDOMAIN.

A DNS client that is aware of RFC 9824 can also set the CO flag, standing for Compact Answers OK, informing the resolver that it knows how to interpret compact denial of existence even if the response code is NXDOMAIN. A resolver implementing RFC 9824 can then set the same flag in the query sent to the authoritative nameserver, which will respond with NXDOMAIN if it implements the optional CO-signaled code restoration.

If all hops support this mechanism and set the CO flag, the client receives NXDOMAIN and doesn't need to read the NXNAME bit. If any of the hops, including the client, doesn't set the CO flag, the response code is reverted to NOERROR and the client ultimately receives NOERROR. This mechanism, defined in Section 5.1 of RFC 9824, is however optional, although "recommended".

According to our research, Cloudflare, NS1, AWS Route 53, Azure DNS and Oracle Cloud DNS authoritative servers don't appear to support response code restoration with the CO flag, while Bunny DNS does. DNS libraries and tools (like dig) don't set the CO flag by default, even when DNSSEC is requested.

All response code restoration mechanisms are optional and they don't appear to be widely deployed currently. Most DNS queries are likely to fall into the non-DNSSEC bucket, and none of the popular DNS resolvers we tested currently restores NXDOMAIN as suggested by RFC 9824. When a client decides to request DNSSEC data from a resolver (DO bit), NXDOMAIN restoration does not apply automatically. It needs every hop in the resolution chain to set the CO flag: according to our research (June 2026), popular resolvers BIND9, Unbound, PowerDNS and Knot Resolver don't set this flag for outgoing queries to authoritative servers.

Real-world impact

The issue of a DMARC client not detecting non-existent domains properly is present when the domain uses DNSSEC and its authoritative nameserver uses compact denial of existence. Several surveys estimate the percentage of domains using DNSSEC signing at around 8-10%. According to this research conducted in December 2024 on the top one million domains, out of the 73k domains with valid DNSSEC 44% were using NSEC compact denial.

This is confirmed by the fact that many major DNS providers use compact denial of existence, although full support for RFC 9824 is inconsistent:

Some DNS authoritative servers implement NSEC "black lies" but not the full RFC 9824 specification, which requires the NXNAME bit to be set in responses. Notably, Azure DNS mentions implementing RFC 9824 while it's not true in practice; Bunny DNS mentions supporting "black lies" while fully supporting RFC 9824 in practice. Find the commands used for testing here.

As for DMARC implementations, we cannot know what closed-source ones do, i.e. whether they support the np tag, how they check for NXDOMAIN, whether they use DNSSEC or are aware of RFC 9824 and the NXNAME bit. We can however determine this for open-source implementations. We analyzed the following popular open-source DMARC implementations:

• OpenDMARC doesn't fully support the np tag yet, but it enables DNSSEC when available. It does not set the CO flag, so NXDOMAIN restoration would not apply even if supported by the resolver. It is not aware of RFC 9824 and the NXNAME bit.
• Stalwart (mail-auth) does not fully support the np tag yet, does not use DNSSEC and is not aware of RFC 9824.
• Mail::DMARC supports the np tag, checks for NXDOMAIN strictly treating NODATA as existence, does not use DNSSEC and is not aware of RFC 9824.
• Rspamd does not support the np tag, does not use DNSSEC and is not aware of RFC 9824.
• Postal Systems mailauth does not support the np tag, does not use DNSSEC, is not aware of RFC 9824 but treats both NXDOMAIN and NODATA as non-existence.
• Maddy (emersion/go-msgauth) does not support the np tag, does not use DNSSEC and is not aware of RFC 9824.

In summary, support for the np tag in DMARC implementations is still sparse, but those who do follow RFC 9989 strictly by checking for NXDOMAIN. With NXDOMAIN restoration not seen in the real world, domains using DNSSEC and the DNS providers listed above would find that the np tag is not applied correctly.

To avoid misclassifying a non-existent domain as existent, implementations would need to deviate from the DMARC RFC and also check for the NXNAME bit on NSEC/NSEC3 records (RFC 9824). This short code snippet shows how to do it. Until all DNS providers support all the mandatory parts of RFC 9824, this won't be perfectly reliable.

Finally, one aspect to consider is that many mail servers reject mail when the Envelope From domain has no MX or A/AAAA records. When the Envelope From domain and From domain are identical, this may reduce the number of relevant cases. The np tag was nonetheless introduced, so it was probably deemed realistic that a mail receiver reaches the point where the np policy is evaluated.

Raising the issue at the IETF

We raised the issue of the incompatibility of the np tag with Compact Denial of Existence on the mailing list of the DMARC working group. You can read the whole thread here. In short, the issue was not found to be suitable for an erratum, which is usually reserved for typos or technical errors (an engineer at bunny.net submitted the erratum report). Opinions differ, but it currently seems unlikely that the DMARC RFC will be revised to mention RFC 9824.

Further discussion happened in the dnsop mailing list, where it was mentioned that some mainstream resolvers are considering introducing NXDOMAIN restoration, with options including updating RFC 9824 to make response code restoration mandatory (MUST) or strongly recommending it (SHOULD), or changing RFC 9989 (DMARC) to account for RFC 9824. At the time of writing, discussions have been stale for a few weeks and there doesn't appear to be a strong consensus on moving forward with either of these options.

Conclusion

Most DMARC implementations don't currently support the new np tag (non-existent subdomain policy), but when they do, it's likely that it won't be applied correctly to DNSSEC-signed domains hosted by DNS providers using compact denial of existence. As we've seen, many large DNS providers use compact denial and many domain names using DNSSEC are therefore affected.

DMARC implementations can choose to deviate from RFC 9989 (DMARC) to account for RFC 9824 (compact denial of existence) and recognize the NXNAME bit on NSEC/NSEC3 records. Alternatively, the solution is to ensure that NXDOMAIN restoration and the CO flag are consistently supported and used in the DNS resolution ecosystem. For domain owners, it's wise to assume that using the np tag will not be guaranteed to work in practice.