Why can DMARC's np tag fail with DNSSEC?
Updated on 14 Sep 2026: We clarified which DMARC implementations skip np and corrected the DNSSEC testing guidance.
DMARC's np tag can fail with DNSSEC because some DNSSEC authoritative servers use compact denial of existence. They return NOERROR with a signed NSEC or NSEC3 proof and an NXNAME signal for a name that does not exist. RFC 9989 defines a nonexistent domain by an NXDOMAIN response. A DMARC evaluator that checks only the response code therefore treats the name as existing and skips np, even though DNSSEC has proved that the name does not exist.
DNSSEC validation has not failed in this case. The failure sits at the boundary between DMARC's NXDOMAIN test and RFC 9824's compact DNSSEC response. Treat np as defense in depth until receivers, resolvers, and authoritative servers handle NXNAME consistently. Keep DNSSEC enabled and set a strict sp policy where operationally safe. Aggregate reports can support that rollout, but they do not prove that every receiver enforces np.
The practical limitation
Publishing np=reject does not guarantee that a receiver will request rejection of DMARC-failing mail using a nonexistent subdomain. The receiving system decides whether the RFC5322.From domain is nonexistent, and many implementations either lack np support or depend only on NXDOMAIN.
Where the np policy fits
RFC 9989 imported np from RFC 9091 into the core DMARC specification. It defines the policy for nonexistent subdomains beneath the domain that publishes the DMARC record. It complements p, which controls the policy domain, and sp, which controls existing subdomains without their own DMARC policy. A child domain with its own DMARC record still uses that record. The sp tag behavior matters because sp becomes the likely fallback when a receiver misclassifies a nonexistent child as existing.
Example DMARC policyDNS
v=DMARC1; p=none; sp=quarantine; np=reject; rua=mailto:dmarc@example.com
With this record at _dmarc.example.com, mail using an RFC5322.From domain of ghost.example.com should receive the reject policy if ghost.example.com does not exist. Mail using an existing child such as news.example.com receives quarantine unless that child publishes its own policy. Mail using example.com receives none.
|
|
|
|---|---|---|
p | Policy domain | None |
sp | Existing child | Quarantine |
np | Missing child | Reject |
Policy selection assumes the receiver identifies existence correctly.
The tag addresses a narrow abuse case. An attacker can invent random labels beneath a real organizational domain, such as invoice-483.example.com, without creating DNS records. np lets the organizational domain publish a specific disposition for those invented names while retaining a different policy for legitimate, existing subdomains.
How compact DNSSEC denial changes the answer
A conventional negative DNS answer returns NXDOMAIN when the queried name and names below it do not exist. DNSSEC must also provide authenticated proof of that absence. Standard NSEC or NSEC3 proofs can require several signed records, especially when the server must prove both that the exact name is absent and that no wildcard covers it.
Compact denial of existence, historically called 'NSEC black lies', reduces that response. A conforming RFC 9824 authoritative server returns NOERROR with no requested data and includes a signed NSEC or NSEC3 record. The NXNAME bit in that record communicates that the queried name itself does not exist. Older command-line software can display the assigned type as TYPE128 instead of NXNAME. Earlier compact-denial deployments can omit NXNAME, which leaves applications unable to distinguish a missing name from an existing empty non-terminal by the bitmap alone.
Compact DNSSEC proves a subdomain is missing but returns NOERROR, so np can be skipped.
Conventional negative answer
The resolver returns NXDOMAIN. A strict RFC 9989 evaluator sees the response code, identifies a nonexistent subdomain, and selects np.
- Signal: NXDOMAIN is visible in the DNS header.
- DMARC result: The evaluator can select np directly.
Compact signed answer
The resolver returns NOERROR plus an authenticated NXNAME proof. An evaluator that ignores the proof sees an existing name and does not select np.
- Signal: NXNAME sits inside the signed denial record.
- DMARC result: np is skipped unless the evaluator understands NXNAME.
The exact failure path
The mismatch requires several conditions. The visible From domain must be a nonexistent subdomain, the organizational domain must publish np, and the DNS zone must be signed. Its authoritative service must use compact denial, while some part of the receiving path must fail to translate or interpret NXNAME. np also has to be supported by the receiver in the first place.
- Policy discovery: The receiver finds the organizational DMARC record containing np=reject.
- Existence query: It asks DNS about the RFC5322.From domain used by the message.
- Compact proof: DNS returns NOERROR and a signed denial record carrying NXNAME.
- Wrong classification: The evaluator tests only for NXDOMAIN and treats the child as existing.
- Weaker disposition: The receiver applies sp, or p when sp is absent, instead of np.
RFC 9824 defines optional signaled response-code restoration through the resolution chain. A resolver sets the Compact Answers OK (CO) flag to say it accepts a signed NXNAME proof with an NXDOMAIN response code. This is hop-by-hop behavior, so it only helps when each participating resolver and the authoritative server support the mechanism. A domain owner cannot force the receiver's DNS path to restore NXDOMAIN.
DNSSEC is not the defect
The signed denial can be cryptographically valid. Turning off DNSSEC removes useful DNS integrity protection and does not solve uneven receiver support for np. Keep DNSSEC and design the DMARC policy so np is an extra control, not the only control.
Which implementations are affected
The interoperability problem affects a DNSSEC-signed zone only when its authoritative server emits compact denial and the receiving path delivers NOERROR to a DMARC engine that depends on NXDOMAIN. DNSSEC zones using conventional denial are not exposed to this specific mismatch.
|
|
|
|---|---|---|
No np support | np is an unknown tag | Uses sp or p |
np support with NXDOMAIN-only testing | NOERROR with NXNAME | Skips np |
DNSSEC-aware NXNAME testing | Validated NXNAME proof | Can apply np |
CO-based response restoration | Restored NXDOMAIN | Can apply np |
Implementation behavior determines whether np applies after a compact denial response.
For a specific receiver, confirm behavior through published code, implementation documentation, or a controlled mail test. Closed receiving systems often do not document whether they support np or inspect NXNAME. Aggregate DMARC reports show authentication and disposition outcomes, but they do not expose the resolver response or the evaluator's existence test.
How to test whether a domain is exposed
First validate that the organizational domain publishes one syntactically valid DMARC record and that np appears where expected. The DMARC checker catches duplicate records, invalid tags, and policy syntax problems. Those are separate from the compact denial issue, but they must be removed before the DNSSEC result means anything.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Next, query a randomly generated label beneath the policy domain through a validating recursive resolver. Use a label that has never existed so cached or stale records do not confuse the result. The +dnssec option requests DNSSEC records, but it does not validate them by itself. Check for the AD flag from the validating resolver before treating the proof as authenticated. Repeat through the recursive resolvers that matter to your testing because one resolver can restore or transform a response while another passes it through.
Query a nonexistent childBASH
dig ghost-7f31.example.com A +dnssec \ +noall +comments +authority
Compact denial patternDNS
;; status: NOERROR ;; flags: qr rd ra ad ghost-7f31.example.com. 300 IN NSEC \ \000.ghost-7f31.example.com. RRSIG NSEC TYPE128
NXDOMAIN indicates the conventional signal that RFC 9989 expects. NOERROR plus a validated NXNAME or TYPE128 proof indicates compact denial and the interoperability risk. NOERROR without NXNAME can indicate an older compact-denial implementation, a true existing name with no record of the requested type, or a response altered along the path. Test more than one record type and inspect the signed proof before drawing a conclusion.
Controls domain owners can apply now
The safest response is to reduce the policy difference between existing and nonexistent subdomains. If legitimate child domains are ready for enforcement, set sp=reject as well as np=reject. Then a receiver that wrongly classifies an invented child as existing still reaches a reject policy. Publish a child DMARC record where a real subdomain needs a different disposition.
Risky policy gap
Different outcomesDNS
v=DMARC1; p=none; sp=none; np=reject
A missed nonexistence test can turn the intended reject into monitoring only.
Resilient policy
Matched outcomesDNS
v=DMARC1; p=reject; sp=reject; np=reject
The classification error no longer weakens the requested disposition.
Stage that change using aggregate reports. Inventory every legitimate sender and verify that each source passes SPF or DKIM with a DMARC-aligned domain. Move known exceptions to explicit child policies before raising sp. A sudden sp=reject change can block legitimate mail sent by forgotten services. Continuous DMARC monitoring shows which sources still depend on the organizational policy.
- Keep DNSSEC: Do not trade authenticated DNS answers for an unreliable np workaround.
- Tighten sp: Use reject when all legitimate subdomain traffic is authenticated.
- Create exceptions: Publish explicit child policies for real subdomains that need staging.
- Avoid wildcards: A wildcard changes DNS existence semantics and can prevent np from applying.
Receivers often perform other checks before or alongside DMARC. Some reject mail when a return-path domain lacks required address or mail records, but that check concerns RFC5321.MailFrom and does not reliably protect an invented RFC5322.From domain. Local anti-abuse rules also vary. They reduce exposure in some paths, but they do not make np portable.
What receiver implementers need to change
A receiver cannot treat every NOERROR with an empty answer as nonexistence. That would confuse NODATA for an existing name with proof that the name itself is absent. The evaluator needs DNSSEC-aware access to the authenticated NSEC or NSEC3 proof and must identify NXNAME, or it needs a resolver that reliably restores NXDOMAIN.
Safe classification rule
Select np after a validated NXDOMAIN response or after a validated compact denial proof that contains NXNAME for the queried name. Treat plain NOERROR with empty requested data as NODATA, not as proof of nonexistence.
Implementation tests should cover conventional NSEC, NSEC3, compact NSEC, compact NSEC3, wildcard denial, unsigned zones, bogus signatures, and resolvers that strip DNSSEC material. They should also test the policy fallback when np is absent. Closed receiving systems rarely document these details, so senders should assume mixed behavior across the internet.
How Suped supports a safer rollout
Suped's DMARC reporting and email authentication platform helps teams inventory legitimate subdomain senders before tightening sp. Review aggregate report data to find sources that fail DMARC, then verify SPF or DKIM alignment before changing the inherited subdomain policy. This workflow reduces the risk of blocking legitimate mail during enforcement.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped's Hosted DMARC workflow supports policy staging and record management across domains. Use it to handle explicit child policies before moving sp to reject. Suped cannot force an external receiver to interpret NXNAME or support np, so the practical goal is to make the inherited sp policy safe and reduce dependence on np.
Views from the trenches
Best practices
Treat np as defense in depth and keep the subdomain policy strict wherever operations allow.
Test random child labels through several resolvers and inspect signed denial records closely.
Review aggregate DMARC data before changing sp so legitimate subdomain mail stays protected.
Common pitfalls
Assuming NOERROR means a DNS name exists can cause compact denial proofs to be ignored.
Disabling DNSSEC to recover NXDOMAIN removes protection without fixing receiver variation.
Relying on return-path domain checks does not secure every invented visible From domain.
Expert tips
Match sp and np at reject where possible, then publish child exceptions deliberately.
Check for NXNAME or TYPE128 inside validated NSEC data, not only the response status.
Keep test labels unique so cached answers do not hide current authoritative behavior.
Marketer from Email Geeks says implementers should review the relevant DMARC and DNS standards discussions because the issue crosses both specifications.
2026-07-06 - Email Geeks
Marketer from Email Geeks says receivers should question mail that uses a nonexistent visible From domain, regardless of whether np is evaluated.
2026-07-06 - Email Geeks
Build policy around mixed receiver behavior
np fails when a valid compact DNSSEC denial says NOERROR while DMARC expects NXDOMAIN, and the evaluator does not read NXNAME. The problem depends on the DNS provider, recursive path, and receiver implementation, so changing one sender-side DNS tag cannot make enforcement uniform.
Keep DNSSEC, validate the published record, test negative answers, and treat np as an additional policy. Where legitimate traffic permits it, sp=reject closes the practical gap because both existing and misclassified nonexistent children receive the same disposition. Use explicit child records for controlled exceptions and use aggregate data to stage the change safely.
