Why DMARC's new "np" tag can fail with DNSSEC
← Blog Last updated<br>Jul 5, 2026<br>Why DMARC's new "np" tag can fail with DNSSEC<br>Matteo<br>18 min. read<br>The recently updated DMARC specification, published as RFC 9989, introduces the new np tag. Its purpose is to specify the policy that receivers should apply when the sender domain is a non-existent subdomain of the domain where the DMARC record is published.<br>We discovered that the definition of “non-existent domain” contained in RFC 9989 clashes with another recent specification, RFC 9824, known as ”Compact Denial of Existence in DNSSEC ”, resulting in the np tag not always working as expected. Although DNSSEC usage is far from being widespread, the issue affects all domains using DNSSEC with major DNS providers like Cloudflare, NS1, AWS Route 53 and Azure .<br>We raised the issue with the IETF working group responsible for DMARC: the issue was acknowledged but no solution was agreed upon. In this article, we’ll explain the whole story and try to assess the impact of this incompatibility.<br>The new np tag<br>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 .<br>In a DMARC record, it looks like this:<br>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.<br>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.<br>Non-existent subdomains in the DNS<br>The DMARC RFC defines non-existent domains as follows:<br>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:<br>~ ❯ dig non-existent-subdomain.rai.it +noall +comments +answer<br>;; Got answer:<br>;; ->>HEADER A different situation is when the specific resource record type that was requested is not found, but other record types for the queried domain exist. In that case, the DNS name exists so the server can’t return NXDOMAIN. It would instead use NOERROR with an empty answer section, also known as NODATA.<br>(A previous experimental extension to DMARC, RFC 9091, specified that non-existent domains are those where there is an NXDOMAIN or NODATA response for A, AAAA, and MX records, explicitly mentioning that this is a broader definition than that in RFC 8020. This definition was changed when it was incorporated into RFC 9989.)<br>In the above example, we can determine that the non-existent-subdomain.rai.it name and all its subdomains don’t exist.<br>On the other hand, in the following example we can determine that the domain news.rai.it doesn’t have MX records, but it exists because it has other record types:<br>~ ❯ dig news.rai.it MX +noall +comments +answer<br>;; Got answer:<br>;; ->>HEADER In the DNSSEC world, things get a bit more complicated.<br>DNSSEC in short<br>DNSSEC is a security extension for DNS that lets resolvers verify that DNS answers are authentic and haven’t been tampered with. It does so by adding cryptographic signatures that resolvers can verify.<br>In the following example we explicitly ask the DNS resolver to return DNSSEC-related data. We can see that the DNS response contains an additional record in the ANSWER section, with type RRSIG.<br>~ ❯ dig dmarcwise.io +dnssec +noall +comments +answer<br>;; Got answer:<br>;; ->>HEADER The RRSIG record contains the signature that the resolver verifies. The verification process involves querying other records in the zone (DNSKEY), and in the parent zone (DS), moving upward in the DNS hierarchy until the root zone is reached.<br>Denial of existence in DNSSEC<br>In standard DNS, queries for non-existent domains produce replies with an empty answer section, as we’ve seen above. This doesn’t play well with DNSSEC because an empty ANSWER section contains no records, so there’s nothing to sign .<br>DNSSEC solves this using the NSEC record type. Instead of signing the non-existent name, it identifies an existing name coming before the requested name and reports the next existing name in canonical DNS order, proving that the requested name does not exist between them . The NSEC record is then signed so that any alteration can be detected. The DNS response code remains NXDOMAIN.<br>For example, a zone may contain the following domain names:<br>a.example.com<br>z.example.com When we query domain...