The Conflict Between DMARC's New `np` Tag and DNSSEC

Last updated: July 5, 2026 Author: Matteo Reading Time: $\approx 18$ minutes

The DMARC landscape has recently evolved with the publication of RFC 9989, which introduces a specific new element: the np tag.

While intended to strengthen email security, we have discovered a technical collision. The definition of a "non-existent domain" in RFC 9989 conflicts with RFC 9824 (which covers Compact Denial of Existence in DNSSEC). This means that in certain environments, the np tag may not function as intended.

Despite DNSSEC not being universal, this incompatibility impacts any domain utilizing DNSSEC through major providers, including:

Cloudflare
AWS Route 53
Azure
NS1

The IETF working group for DMARC has been notified. While they have acknowledged the problem, a formal resolution has not yet been reached. This article explores the technical roots of this issue and its potential impact.

Understanding the `np` Tag

Published in May 2026, the updated DMARC specifications (spanning three documents) introduced the np tag, which stands for non-existent subdomain policy.

Consider the following DMARC record: v=DMARC1; p=none; sp=quarantine; np=reject;

To understand how this works, we can look at the hierarchy of policies:

Tag	Scope	Application
`p`	Organizational Domain	Applies to the primary domain where the record is hosted.
`sp`	Existing Subdomains	Applies to subdomains that exist but lack their own DMARC record.
`np`	Non-existent Subdomains	Applies to subdomains that do not exist in the DNS.

By utilizing these distinct tags, administrators can implement a "strict" policy (like reject) to block spoofing on unused subdomains while maintaining a more permissive policy (like none) for active ones.

Defining "Non-existence" in DNS

The DMARC specification relies on a specific definition of what constitutes a non-existent domain:

"For DMARC purposes, a non-existent domain is consistent with the term’s meaning as described in RFC 8020."

Essentially, if a DNS query returns an NXDOMAIN (Non-Existent Domain) response code, the domain—and any potential subdomains beneath it—are considered non-existent.

NXDOMAIN vs. NODATA

It is crucial to distinguish between a domain that doesn't exist and a domain that exists but lacks a specific record.

NXDOMAIN: The name is completely absent.

~ ❯ dig non-existent-subdomain.rai.it +noall +comments +answer
;; Got answer:
;; ->>HEADER - opcode: QUERY, status: NXDOMAIN, id: 17031

NODATA: The name exists (it has other records), but the requested type (e.g., MX) does not. This returns NOERROR with an empty answer section.
```
~ ❯ dig news.rai.it MX +noall +comments +answer
;; Got answer:
;; ->>HEADER - opcode: QUERY, status: NOERROR, id: 37891
```

~~Previously, RFC 9091 (an experimental extension) defined non-existent domains as those returning either NXDOMAIN or NODATA for A, AAAA, and MX records.~~ This broader definition was discarded when the logic was integrated into RFC 9989.

The Role of DNSSEC

DNSSEC (Domain Name System Security Extensions) adds a layer of trust to DNS by allowing resolvers to verify that data is authentic and unaltered via cryptographic signatures.

When requesting DNSSEC data, you will see an RRSIG record in the answer section:

~ ❯ dig dmarcwise.io +dnssec +noall +comments +answer
;; ANSWER SECTION:
dmarcwise.io. 892 IN RRSIG A 13 2 900 20260801080000 20260704073000 20768 dmarcwise.io. bPF4BFfnETKC4GGwrmi0xlOzvBaotX8DG5E8/rpmelxoXJ2eA8RJtUrN JVFjFVCq5ZP/Ul9XYgT86c8Vw5Y4Sw==

The verification chain works as follows:

Resolver checks the RRSIG (Resource Record Signature).
Resolver queries the DNSKEY in the current zone.
Resolver validates the DS (Delegation Signer) record in the parent zone.
This continues up to the root zone.

The Conflict: Denial of Existence

In standard DNS, proving something doesn't exist is easy: just send an empty response. However, in DNSSEC, you cannot sign "nothing." To prove a name doesn't exist, DNSSEC uses NSEC (Next Secure) records.

Instead of signing the void, the server identifies the "gap" between two existing records in canonical order.

How NSEC Works

If a zone contains only a.example.com and z.example.com, and a user queries f.example.com, the server responds with an NSEC record stating: "The record after a.example.com is z.example.com."

The server then provides a signed RRSIG for that NSEC record. This proves that no names exist between $A$ and $Z$ .

The Core Issue

The conflict arises because the np tag relies on a strict NXDOMAIN response. However, the "Compact Denial of Existence" (RFC 9824) used by many modern DNSSEC providers changes how these non-existence proofs are delivered. If the resolver or the provider's implementation of DNSSEC doesn't align perfectly with the NXDOMAIN requirement of RFC 9989, the DMARC receiver may fail to trigger the np policy.

Current Status of the Issue:

Discovered incompatibility between RFC 9989 and RFC 9824.
Reported to IETF DMARC working group.
Acknowledged by the IETF.
Agreement on a technical solution.

The Conflict Between DMARC's New np Tag and DNSSEC

Understanding the np Tag