GoKawiilLast updated Jul 5, 2026
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.
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.
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.
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.
... continue reading