A subdomain's DMARC result depends on the policy discovered for its visible From domain and the message's aligned authentication. A parent record is useful evidence, but it does not establish the full result for every child.
Start with the exact Author Domain, meaning the domain in the visible From address. Determine whether it has an explicit applicable policy, how discovery proceeds when it does not, and which current policy semantics the implementation applies.
Begin with the exact child identity
Protocol references: RFC 9989 §4.10.1, RFC 9989 §5.3.6. Operational checklists and decisions below are editorial guidance.
Record the child's legitimate services, DNS authority and representative messages. A separately delegated child zone can have a different publishing account and owner.
Query the intended _dmarc name and preserve the full response. Distinguish absence from resolution failure. Finding no direct child policy does not, by itself, establish that no policy can be discovered.
Use the current discovery specification and implementation evidence. Avoid reducing organisational boundaries to the final two labels or assuming every receiver has identical legacy and updated behaviour.
Separate p, sp and np
Protocol references: RFC 9989 §4.7, RFC 9989 §4.10.1. Operational checklists and decisions below are editorial guidance.
Under current RFC 9989, the applicable organisational-domain policy distinguishes the domain itself, existing subdomains and non-existent subdomains.
- Tag: p; Relevant scope when applicable: The domain's policy, also providing applicable fallback
- Tag: sp; Relevant scope when applicable: Existing subdomains of the prevailing organisational domain
- Tag: np; Relevant scope when applicable: Non-existent subdomains of that organisational domain
The np fallback is sp when present, otherwise p. The current specification also explains why sp in a policy published on a subdomain does not become a general override for all deeper names.
The absence of an MX record alone is not a complete domain-existence test. Follow the specified discovery and existence handling rather than classifying a domain from one short DNS display.
Work through a scoped policy example
Protocol references: RFC 9989 §4.10.1. Operational checklists and decisions below are editorial guidance.
Assume, solely for this synthetic example, that example.com is the prevailing organisational domain and the receiver implements the current rules. Its policy is:
v=DMARC1; p=none; sp=quarantine; np=rejectAssume news.example.com exists and has no direct policy that changes the discovered result. The parent policy's sp assessment is relevant for failing mail using that existing child. For a child established as non-existent under the applicable rules, np is relevant.
Now suppose pay.example.com has its own valid explicit policy:
v=DMARC1; p=rejectThat child's applicable direct record must be assessed in discovery. The parent's none value is not a sufficient description of the child's policy. Equally, do not infer every grandchild's result merely by appending sp to that child record.
These examples describe policy selection under their assumptions. They do not claim that all deployed receivers implement every updated behaviour or that a requested disposition occurs universally.
Verify authentication on the child's real routes
Protocol references: RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5. Operational checklists and decisions below are editorial guidance.
Inspect original received mail from each important child-domain service. Compare From, the SPF identity and relevant DKIM d= identities under the applicable alignment modes.
A child policy does not configure signing for the child. A service might authenticate its own unrelated domain, while another service's supported signing configuration aligns successfully.
Use the alignment guide to establish the passing path. Test after final gateways or forwarding routes rather than relying only on an isolated direct send.
Approve policy changes against the child domain's use
Protocol references: RFC 9989 §7.4. Operational checklists and decisions below are editorial guidance.
A dedicated application subdomain can differ from a correspondence or mailing-list domain. Review current interoperability guidance and the business consequences before proposing reject.
Keep the exact record changes, authority, approver and recovery conditions. If parent and child settings are changed together, record the dependency and test each affected Author Domain separately.
A statement such as all subdomains protected needs a defined scope and evidence. Include delegated zones, dormant services and unresolved ownership rather than treating one parent lookup as a portfolio assessment.
Retain the evidence needed to explain an outcome
For each assessed identity, keep the queried name, effective discovered policy, relevant p/sp/np interpretation, DNS observations, implementation context and received-message results.
Reassess when a child zone is delegated, a service is introduced or the domain's purpose changes. DMARCbis readiness covers updated discovery dependencies, while the sender inventory keeps the legitimate routes accountable.
Apply the evidence without overstating it
In the parent-policy fixture, existing news uses quarantine only under the stated discovery assumptions; the established non-existent child uses reject, and pay’s valid direct policy uses reject. Requested assessment still does not guarantee final handling. Keep the actual query and policy-selection trace rather than inventing a test outcome.