Existence belongs to the domain, not one record type
The np tag supplies a DMARC assessment policy for nonexistent subdomains under the applicable discovered policy. It is useful only when the existence decision is sound. “No A record,” “no DMARC TXT record” and “the Author Domain does not exist” are different statements. Treating them as synonyms can apply the wrong policy to a real domain or conceal a resolution outage behind a false negative answer.
RFC 9989 section 4.7 distinguishes np from sp. The former addresses nonexistent subdomains; the latter addresses existing subdomains. Neither substitutes for determining which policy record applies. The Author Domain's own valid policy has priority, and its p tag is used for that domain. Parent-policy calculations come later, when the Author Domain has no applicable policy of its own.
Specify the parent and keep the examples fictional
Use north.example as an invented organizational domain with this policy: v=DMARC1;p=none;sp=quarantine;np=reject;psd=n. Assume every case below uses an otherwise valid message whose authentication does not produce an aligned pass. These are documentary fixtures with manually derived outcomes, not DNS observations, delivery attempts or statements about any organization's records.
For live.north.example, stipulate an address record and no own DMARC policy. Discovery reaches the parent boundary, and existence is established. The requested assessment comes from sp=quarantine. The parent's p=none does not replace the more specific existing-subdomain preference. Preserve the selected tag in the result so a reviewer can see why quarantine was chosen.
For empty.north.example, stipulate an MX record but no A record. An A query's authoritative NOERROR/NODATA response is compatible with that existing name. With no own DMARC policy, sp=quarantine still applies. This case deliberately separates a missing record type from a missing domain; a checker that labels it nonexistent merely because it asked only for A would fail the expected decision.
Interpret NXDOMAIN at the right name
For gone.north.example, stipulate an authoritative NXDOMAIN response for the Author Domain itself, without an alias chain, and no own policy. The selected parent policy uses np=reject. RFC 9989 Appendix A.4 explains that DMARC existence does not require a particular mail-related record type. Its definition follows DNS existence rather than SMTP's narrower notion of a resolvable destination.
An NXDOMAIN response for _dmarc.live.north.example would deny that queried child name, not prove that live.north.example is absent. The direction of the inference matters. RFC 8020 explains that a denied name also has no descendants; it does not say that denial of a child erases its parent. Alias processing can also make the denied name different from the original question, so retain the actual name whose existence was denied.
An empty nonterminal is another useful boundary case: a node can exist in the DNS hierarchy because it has descendants even when it has no records of its own. Do not collapse that structural existence into NXDOMAIN. The fixture designer should specify the tree, not merely a convenient text label attached to an empty answer.
Inspect NODATA and resolution failures separately
NODATA is not an independent DNS response code. RFC 2308 section 2.2 describes a negative-answer classification that needs response context. A blank Answer section can accompany a referral, and aliases can affect which name and type were actually resolved. Save the question, response code, alias chain and authority information before drawing an existence conclusion.
SERVFAIL, timeout and an incomplete response are not evidence of nonexistence. RFC 1035 section 4.1.1 distinguishes server failure from name error. In the fictional broken.north.example case, SERVFAIL leaves existence unresolved; it does not select np by itself. RFC 9989 section 4.10.1 leaves DNS-error handling to receiver discretion, including possible temporary deferral. An evaluator must retain this unresolved state instead of claiming a normal negative lookup.
Apply policy precedence and fallback deliberately
Now give own.north.example a valid v=DMARC1;p=none policy at its exact _dmarc name. Its own p value supplies the assessment; the parent's np and sp preferences do not replace it. This is a policy-discovery rule, not an exception invented for permissive child domains. Existing child configuration still needs an authorized owner and a reasoned security review.
If np is absent from the selected parent record, its section 4.7 default is sp when sp exists, otherwise p. For the example parent, removing np makes the nonexistent-subdomain assessment quarantine. Removing both np and sp leaves none. This fallback deserves a separate test because a shortcut that jumps directly from missing np to p would ignore the documented sp default.
Testing mode and receiver handling remain additional layers. If the applicable record includes t=y, derive the selected policy first and then apply its testing semantics. A requested reject assessment also is not an assurance of a final rejection: receiver analysis and the interoperability requirements in RFC 9989 remain relevant. The table accompanying this article records policy selection, not observed inbox placement.
Preserve an evidence packet instead of a green badge
The exact commission is: Compare existing, NODATA and NXDOMAIN cases and derive the selected policy. The fictional comparison supports review of the expected logic, but it does not close the original operational-evidence gate. No live queries, controlled authority fixtures or receiver outcomes were collected. Current errata review is also unresolved after inaccessible endpoints were stopped.
An approved follow-up should retain the exact Author Domain, applicable policy record, existence evidence, fallback path, receiver version and resulting assessment. Keep DNS-engineering review separate from mail-policy ownership. Production applicability, specialist review, visual acceptance and publication permission remain pending. A reliable np explanation makes uncertainty visible precisely where a careless tool might hide it.