What this analysis does
Enter any real domain to inspect each _dmarc lookup in the RFC 9989 Tree Walk, see which valid policies were discovered, identify psd=n or psd=y boundaries, and understand why a particular Organizational Domain is selected.
Under the current DMARC standard, finding the policy that applies to a domain is a discovery procedure rather than a single lookup. The tree walk queries a bounded sequence of names and stops at the first valid policy. Seeing that sequence is what makes an inherited policy auditable instead of assumed.
Why one lookup is not enough
A subdomain frequently has no DMARC record of its own and is still governed by a policy published higher in the tree. Querying only the direct name and reporting nothing found is a false negative that has real consequences, because it suggests a domain is unprotected when an inherited policy is in force.
RFC 9989 replaces the older public suffix approach with a bounded walk up the name hierarchy. The procedure has a defined query limit, so it terminates predictably rather than walking to the root. Recording each query and its outcome turns policy selection into evidence you can attach to a change record.
- The walk is bounded, not unlimited.
- The first valid policy encountered is the one that applies.
- A missing direct record does not mean DMARC is absent.
The organizational boundary is discovered, not assumed
Earlier practice determined the organizational domain from a static public suffix list that had to be distributed and kept current. The tree walk derives the boundary from what is actually published in DNS, which removes the dependency on a snapshot that can be stale.
Explicit markers participate in that determination. A psd tag can declare that a name is or is not a public suffix domain, which lets operators of unusual namespaces state the boundary directly instead of relying on external list maintenance.
Subdomain policy inherits differently than people expect
An organizational record can carry sp for subdomains and np for non-existent subdomains. Both are commonly overlooked, with the result that a domain enforcing rejection at the apex leaves subdomains under a weaker policy simply because sp was never set.
The np tag is particularly useful for defence. Attackers frequently invent subdomains that were never registered in DNS, and np lets a domain declare a strict policy for exactly that case without affecting subdomains that legitimately exist.
Validate the discovered recordTest alignment against the discovered policy
Example: policy inherited two levels up
Evidence supplied
Author domain: billing.eu.example.com, with no record at the direct DMARC name.
How to read the result
The walk records each queried name in order and reports the first valid policy it finds, along with the level at which it was discovered and whether subdomain instructions apply. The discovery path is shown so the selected policy can be justified.
Known limits
- Results describe DNS as observed at query time and can differ under caching or split-horizon resolution.
- A discovered policy does not prove that any particular message passed DMARC.
- Receivers may implement discovery with minor differences during the transition to the current standard.
Common questions
Does every subdomain need its own DMARC record?
No. A subdomain can inherit an applicable organizational policy. Publish a direct record only when that subdomain needs deliberately different handling or separate reporting.
What replaced the public suffix list?
A bounded DNS tree walk defined by RFC 9989, which derives the organizational boundary from published records rather than from a distributed static list.
What does np do?
It sets the policy applied to subdomains that do not exist in DNS, which is a common target for spoofing attempts.