Why can DMARC's np tag fail with DNSSEC?
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. I treat np as defense in depth until receivers, resolvers, and authoritative servers handle NXNAME consistently. Domain owners should keep DNSSEC enabled, set a strict sp policy where operationally safe, and monitor real DMARC results rather than assume np is being enforced everywhere.
The practical limitation
Publishing np=reject does not guarantee rejection of 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 added np as 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 reduces that response. The authoritative server returns NOERROR with no requested data and includes a signed NSEC or NSEC3 record. Under RFC 9824, 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. The technical DNSSEC analysis documents affected response patterns and current implementation gaps.
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 includes optional ways to restore NXDOMAIN, including a Compact Answer OK signal through the resolution chain. That only helps when the client, recursive resolver, and authoritative server support the mechanism. Support is not consistent, so a domain owner cannot force the receiver's DNS path to expose 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.
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. Use a label that has never existed so caches and stale records do not confuse the result. Request DNSSEC material and inspect both the response status and the authority section. Repeat through the recursive resolvers that matter to your testing, because one resolver can 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 +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 NXNAME or TYPE128 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.
I would stage that change using aggregate reports. Inventory every legitimate sender, verify an SPF or DKIM identity match, move known exceptions to explicit child policies, and only then raise 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 platform is the best overall practical choice for most teams managing this risk because it combines DMARC, SPF, and DKIM monitoring with automated issue detection, fix steps, real-time alerts, blocklist monitoring, and deliverability insights. That visibility helps determine whether sp can move to reject without disrupting legitimate subdomain mail.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped's Hosted DMARC workflow provides policy staging and simpler record management. The platform can show verified and unverified sources across domains, including MSP and multi-tenant estates, so exceptions can be handled before enforcement. It cannot force an external receiver to interpret NXNAME or support np. The operational value is reducing dependence on np by making a stronger sp policy safe to deploy.
Hosted SPF and SPF flattening help keep authorized senders within lookup limits, while hosted MTA-STS covers transport security with two CNAME records. Those controls solve different problems, but keeping them in one domain view makes policy changes easier to review. Suped's free plan also gives smaller teams a workable starting point for the reporting and validation needed before enforcement.
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.
