Why DNSSEC Breaks the DMARC np Tag on Major DNS Providers

The DMARC "np" tag was added in RFC 9989 (DMARCbis) to solve a specific problem: handling mail from subdomains differently from the parent domain. Where a p=quarantine policy applies to the root domain, the np tag says "but for subdomains, apply no policy at all." It sounds clean. It works in testing. And then it breaks in production after you enable DNSSEC.

The reason is a mismatch between what the np tag promises and what DNSSEC-validating receiving servers actually see when they query your DNS records. This is not a bug in np. It is a gap between how np was designed to work and how DNSSEC validation interacts with it on some of the most widely-used DNS providers.

What the np Tag Was Designed to Do

Before DMARCbis, if you wanted to monitor subdomain mail without affecting it, you had two options: apply p=none to the whole domain, or create a separate DMARC record for each subdomain. Neither was ideal.

RFC 9989 introduced the np tag (None for Policy) specifically for subdomain handling. A record like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; np;

tells receiving servers: "Apply no policy to mail from this domain's subdomains." The receiving server should pass the mail without applying quarantine or reject. The np tag is especially useful when your parent domain is at p=quarantine or p=reject but subdomains use different sending infrastructure and you want to avoid disrupting their mail.

Note: RFC 9989 also removed the "pct" tag from the DMARC specification. If you see pct used alongside np in older configurations, that record is non-compliant with the current standard. Do not add pct to new DMARC configurations.

What DNSSEC Changes About DNS Validation

DNSSEC adds a cryptographic chain to DNS responses. When a receiving mail server queries your domain's DMARC record, DNSSEC validation checks not just that the record exists, but that it has a valid signature proving no one tampered with it in transit.

This works well for verifying authenticity. It causes problems for DMARC when any part of the validation chain is incomplete.

How the Incompatibility Works

When a receiving server validates a DNSSEC-signed response, it walks the chain up to the root. If any link in that chain is broken - a expired signature, a missing DS record, a key that does not match - the entire response is treated as bogus.

For most DNS lookups, a bogus response means "no record found." For DMARC, a bogus or unvalidatable response means the receiver falls back to its own local policy. Which is rarely "apply np."

The specific failure mode for np is this: the parent domain's DNSSEC chain validates correctly, but the receiving server's resolver cannot construct a valid validation path for the subdomain-specific DMARC record (e.g., _dmarc.marketing.example.com). The resolver treats this as "no record" and applies the parent policy to subdomain mail instead of respecting np.

This is more likely to happen when:
- The DNS provider signs the parent zone but not all subdomain record types consistently
- The receiving server uses a resolver with strict DNSSEC enforcement
- The domain has complex subdomain structures with inconsistent DNSSEC coverage

Which Providers Are Affected

The issue is not isolated to one DNS provider. It appears to depend on the combination of:
- How the DNS provider handles DNSSEC signing at the subdomain level
- How strictly the receiving mail server's resolver enforces DNSSEC validation

Cloudflare, Google DNS, and some enterprise email providers with strict DNS hygiene are known to produce inconsistent results for np in DNSSEC-validated environments. The problem is documented in the RFC community but is not yet resolved as a standards gap. It tends to surface when a subdomain that was working fine suddenly starts having mail delivery problems after a DNSSEC configuration change.

A Concrete Example of the Problem

Your domain is example.com. You use Cloudflare for DNS and enable DNSSEC. You publish this record for the parent domain:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; np;

The np tag means subdomain mail should receive no policy. Your marketing subdomain marketing.example.com sends newsletters. When a receiver queries _dmarc.marketing.example.com, it should find no record and fall back to the parent record, which has np.

What actually happens on some receiving servers: the resolver cannot build a valid DNSSEC validation path for _dmarc.marketing.example.com. It treats this as a validation failure and falls back to applying the parent domain's p=quarantine policy. Legitimate marketing mail gets quarantined.

Your aggregate reports may not make this obvious because the receiver processed it under the parent policy, not as a np-specific result.

What to Use Instead of the np Tag

Until the np tag + DNSSEC interaction is more consistently handled, the safest approach is one of the following:

Option 1: Apply p=none to each subdomain directly

Create a specific DMARC record for each subdomain that needs special treatment:

v=DMARC1; p=none; rua=mailto:subdomain-reports@example.com;

This avoids the np tag entirely. Each subdomain gets its own record with explicit policy. The tradeoff is operational overhead if you manage many subdomains.

Option 2: Use p=none for subdomain policy in a single record

If you want a single record that handles both root and subdomains:

v=DMARC1; p=none; rua=mailto:all-dmarc@example.com;

This works for both root and subdomains but applies p=none everywhere. Use it for monitoring before moving to enforcement.

Option 3: Test np thoroughly before relying on it

If you need np, validate that it works correctly with your specific DNS provider and receiving mail servers before deploying it in production. Query your own DMARC record from multiple public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) and compare whether np is returned correctly across all of them.

How to Detect np Tag Problems Before They Cause Mail Disruption

np tag failures caused by DNSSEC issues typically show up in aggregate reports as:
- A subdomain that was sending mail cleanly suddenly experiencing quarantine or rejection despite correct SPF/DKIM alignment
- High volumes of mail from a specific subdomain being subjected to the parent policy instead of no policy
- A sudden drop in subdomain mail delivery coinciding with a DNSSEC configuration change

This is where aggregate DMARC reporting becomes essential, not optional. Without it, you only know about np failures when recipients report missing mail. DMARCFlow monitors your reports continuously and flags when a subdomain that should be under np starts experiencing unexpected policy application. The timeline view makes it straightforward to correlate mail delivery problems with a DNSSEC change you made two days ago, rather than troubleshooting authentication records that are actually correct.

For teams running multiple subdomains with DNSSEC, this is the routine monitoring layer that catches np failures before users notice and before your marketing or product subdomain mail starts landing in spam folders.

Frequently Asked Questions

What is the DMARC np tag and how does it differ from p=none?

The np tag applies no policy specifically to subdomains of the published domain, while p=none applies to the domain itself. If you set p=quarantine and np, the parent domain gets quarantined but subdomains get no policy treatment. p=none applies no policy to everything, including the parent.

Does DNSSEC break the np tag on all providers?

No. The incompatibility depends on how the DNS provider handles DNSSEC signing at subdomain levels and how strictly the receiving mail server validates. Some combinations work correctly. Others do not. The problem is consistent enough to be a known issue but not universal enough to blame a single provider.

How can I tell if my np tag is being ignored?

Check your DMARC aggregate reports for subdomain mail that is being treated under the parent policy instead of no policy. If subdomain mail started having delivery problems after enabling DNSSEC, that is a strong indicator. You can also test by querying your subdomain DMARC record from multiple public resolvers and checking whether np is returned.

Should I disable DNSSEC to use the np tag?

No. DNSSEC adds important DNS security. Instead, use a subdomain-specific DMARC record without the np tag, or test np thoroughly before relying on it in production.

Which DNS providers are affected?

Cloudflare, DNS providers with strict DNSSEC enforcement, and some enterprise DNS setups are known to have this issue. The problem varies by receiving mail server resolver, not just the DNS provider. Test with real receivers to confirm your specific combination.