Why the DMARC np Tag (RFC 9989) Does Not Work Reliably with DNSSEC

If you enabled DNSSEC on your domain and your DMARC np policy seems to be ignored, you have hit a real and documented incompatibility between two RFCs that were written independently. The np tag (RFC 9989) was designed for domains not signing with DKIM, but DNSSEC changes the DNS response semantics in a way that breaks the np lookup for receiving servers performing strict RFC 1035 / RFC 4035 validation.

This is not a bug in your DNS provider. It is a standards-level conflict with a known mechanism.

What the np Tag Is and Why It Was Created

RFC 9989 introduced the np (no policy) flag as a lightweight option for domains that do not sign with DKIM but still want DMARC aggregate reports. Instead of publishing a full DMARC record, these domains can publish a minimal TXT record containing only the np flag, which tells receiving servers that the domain owner wants feedback but is not making any DKIM authentication claims.

The use case was simple: transactional email senders who cannot or do not want to set up DKIM signing, but still want visibility into who is sending mail from their domain.

How DMARC Policy Discovery Works in Normal DNS Lookups

When a receiving server processes an incoming email, it looks up the TXT record for _dmarc.yourdomain.com to find your DMARC policy. Without DNSSEC, this lookup returns one of two outcomes:

• NXDOMAIN if _dmarc.yourdomain.com does not exist, meaning no DMARC policy applies
• A valid TXT record containing your DMARC policy, which tells the receiving server what to do with emails that fail SPF or DKIM alignment

The receiving server then checks SPF and DKIM results against the policy it found.

How DNSSEC Changes DNS Response Semantics

DNSSEC adds cryptographic signatures to DNS records, and with that comes a more precise set of response codes. The one that matters here is the distinction between NXDOMAIN and NODATA.

NXDOMAIN means the DNS name itself does not exist. NODATA means the name exists, but there are no records of the requested type at that name. A NODATA response is a valid, signed NOERROR response with an empty answer section.

RFC 4035 defines this precisely. When a receiving server validates a DNSSEC-signed zone, a NODATA response is a cryptographically confirmed "there is nothing here of this type" rather than "this name does not exist."

Why np Fails When DNSSEC Is Enabled

The np flag assumes a world where DNS lookups return either a record or NXDOMAIN. DNSSEC adds the NODATA case, and RFC 9989 does not define behavior for it.

Here is the specific mechanism:

1. A domain publishes an np flag at _dmarc.example.com and has DNSSEC signatures enabled on the zone
2. A receiving server performs a DMARC policy lookup and DNSSEC validation simultaneously
3. The lookup returns NOERROR with an empty answer section (NODATA), which is a valid DNSSEC response
4. The receiving servers DMARC implementation was written to handle NXDOMAIN as "no policy found," not NODATA as a third state
5. The server either rejects the NODATA as an error or treats it as "no policy found," bypassing np entirely

Some receiving servers handle NODATA correctly. Many do not, because the DMARC spec (RFC 7489) was written before the np flag existed and does not account for this case.

The result is a silent failure. Your np policy is published, DNSSEC is valid, and email is delivered without DMARC policy being applied, with no bounce or error message to alert you.

Who Is Affected

You are affected if all three of these are true:

• Your domain has DNSSEC enabled
• You publish a DMARC np tag (RFC 9989)
• Your email is delivered to receiving servers that perform full RFC 1035 / RFC 4035 DNSSEC validation

This combination is increasingly common. Governments, financial institutions, and regulated industries often have DNSSEC mandated by policy. Managed email providers enable DNSSEC by default. When those two things meet a domain using np, the silent failure activates.

What to Use Instead of np When DNSSEC Is Enabled

The reliable approach is to publish an explicit policy tag instead of relying on np. For domains not signing with DKIM, the options are:

• p=none: receive DMARC reports but do not instruct receiving servers to take action on unauthenticated email
• p=quarantine: instruct receiving servers to treat unauthenticated email as suspicious
• p=reject: instruct receiving servers to reject unauthenticated email outright

For a domain that cannot sign with DKIM but wants visibility, use p=none with an rua aggregate report address. This gives you the same feedback capability as np without the DNSSEC ambiguity.

If you need a minimal record for a domain that genuinely sends no authenticated email, p=none is more widely supported and does not have the same interaction with DNSSEC response codes.

How DMARCFlow Diagnoses This Automatically

This is where DMARCFlow provides immediate practical value. When you add a domain, DMARCFlow performs DNS resolution checks that detect whether your _dmarc record is reachable under both standard and DNSSEC-validated lookups. If your np policy would be ignored under DNSSEC validation, DMARCFlow flags it in the domain diagnostic view before it causes real email delivery problems.

Specifically, DMARCFlow checks whether a receiving server performing DNSSEC validation would reach your np policy or encounter a NODATA response instead. This is not obvious from looking at your DNS records alone. You need to see what the lookup looks like from the outside, through a DNSSEC-validating resolver.

The diagnostic output for each domain shows the _dmarc lookup result with DNSSEC status, so you can confirm whether your policy is actually being applied or silently bypassed. If it is being bypassed, the diagnostic tells you what to change.

For organizations managing multiple domains with DNSSEC enabled, this automatic detection is faster than testing each domain manually against different receiving server configurations.

FAQ

Does p=none have the same DNSSEC problem as np?

No. p=none is an explicit policy tag defined in RFC 7489. It does not have the ambiguity with NODATA response codes that np has. If you need a reporting-only DMARC policy, p=none with an rua directive is more reliable than np when DNSSEC is active.

Which receiving servers fail to apply np with DNSSEC?

Behavior varies by provider and configuration. Servers that perform full DNSSEC validation on _dmarc lookups before applying DMARC policy are more likely to hit this issue. Major inbound email processors vary in their DNSSEC validation behavior, making it difficult to predict which specific servers will apply your np policy and which will silently ignore it.

Is the np tag deprecated?

Not officially. RFC 9989 is a published standard. However, the DNSSEC incompatibility documented here is a known issue that the RFC does not resolve. Until the RFC is updated or implementations converge, using np alongside DNSSEC carries real risk of silent policy failure.

What does RFC 9989 say about DNSSEC?

RFC 9989 defines the np flag but does not comprehensively address the interaction with DNSSEC validation paths. The RFC was written to solve a specific use case (lightweight DMARC feedback without DKIM signing) without fully accounting for the NODATA semantics that DNSSEC introduces.