DMARC Policy Discovery: Parent, Subdomain, and No-Record Outcomes

DMARC policy discovery depends on three outcomes: an explicit record on the queried domain, inheritance from a parent (organizational) domain when the child has none, or a concluded “no record” outcome when neither exists. Operators testing what a receiver will apply must query the exact domain, verify DNS delegation and parent records, and interpret provider-specific behaviors as implementation details rather than protocol guarantees.

How receivers discover DMARC: exact-match then parent lookup

Per the DMARC specification, a receiver looks for an explicit _dmarc TXT record on the queried domain (the policy that applies to the From: header domain). If that exact record exists, its tags determine enforcement and reporting. This is the primary decision boundary: an explicit record on the domain in question wins and stops lookup 1.

If there is no record on the child/subdomain, the receiver will consult the organizational (parent) domain for a policy only when the child has no record and only if the parent has a _dmarc TXT. This parent-lookup behavior is defined in the DMARC RFC; treat it as a protocol-level fallback, not as a substitute for explicit child policies 1.

No-record outcome: when lookup stops with no policy

A 'no-record' result occurs when neither the queried domain nor any parent domain in the organizational chain publishes _dmarc TXT. In that case, the receiver has no DMARC policy to apply and must fall back to its local handling of unauthenticated messages (often specified by the receiver's own spam/abuse policy, not DMARC) 1.

Testing should therefore confirm both the absence of a child record and the absence of a parent record. A DNS NXDOMAIN or NO DATA response for _dmarc on both the child and parent indicates the no-record outcome; be careful to distinguish between a missing TXT and syntactically invalid TXT content.

Subdomain (p=) vs organizational (sp=) policy: decision boundary and precedence

If a child/subdomain publishes its own _dmarc record, that subdomain-level policy (p= tag) controls message disposition for that domain. The organizational domain may include an sp= tag that sets a policy for subdomains, but sp= is only consulted by receivers when a subdomain has no explicit record. Thus precedence is: explicit subdomain record > parent sp= fallback > no policy 1.

Do not assume sp= will be ignored; it is a legitimate mechanism to set a default for any child that has not published its own record. However, because receivers can implement local variations, validate behavior against the specific receivers you care about (some providers publish guidance and known behaviors) 2.

Practical DNS testing sequence and evidence to collect

1. Query _dmarc. TXT for the exact domain you are testing. Record the TXT content, DNS response code, and TTL. 2) If the response is NXDOMAIN or no TXT, query _dmarc on the organizational (parent) domain and record the same details. 3) If delegation exists (the child is a delegated zone), test the authoritative name servers for the child zone directly to avoid cache/misconfiguration artifacts.

Collect a copy of the exact TXT string (for syntax checks), the DNS response types, and timestamps. These items form evidence for why a receiver would choose a specific policy and are useful for debugging disagreements between operators and receivers.

Provider-specific behaviors and limits of inference

RFC 7489 defines the lookup behavior, but real-world application can vary by provider. For example, Google publishes guidance on DMARC handling that can help interpret receiver-specific consequences, but such pages are directional and not normative for all receivers 2. Always treat provider guidance as implementation notes, not protocol law.

When diagnosing a discrepancy between what you publish and what a receiver applies, document the receiver's observed behavior (mail logs, authentication results) alongside your DNS evidence. This clarifies whether the issue is a DNS propagation/delegation problem, a syntax error in the record, or a receiver-specific enforcement choice.

Decision boundaries and stop conditions for operators

Stop after confirming an explicit child _dmarc TXT — that is the authoritative policy for the child. If no child record exists, stop after confirming an organizational _dmarc TXT; that is the fallback the receiver will use (sp= only when child has none) 1.

If neither record exists, stop after verifying delegation and authoritative server responses; the receiver has no DMARC policy to apply and any enforcement observed is not DMARC-derived. Use this as a clear handoff to receiver support when you need them to explain observed disposition.

Practical checklist

• Query _dmarc. TXT and save the full TXT string and DNS response code.
• If no TXT, query _dmarc. TXT and save results.
• Query authoritative name servers for the domain to avoid cached data artifacts.
• Validate TXT syntax per RFC 7489 (required tags like p=, optional sp= and rua/ruf).
• Confirm DNS delegation is correct for subdomains (no unintended zone cuts).
• Test against representative receivers and capture authentication headers (e.g., Authentication-Results).
• If receiver behavior differs, collect mail logs and DNS evidence before contacting provider support.
• Repeat queries from multiple geographic resolvers to detect propagation issues.
• Document timestamps and TTL values for all DNS responses you collect.

Where RepMail fits

Use this guide as a checklist and decision aid when diagnosing outbound authentication problems. Operators can follow the testing sequence and the diagnostic table to produce the evidence packet RepMail or other operational tooling needs for escalation: DNS queries (authoritative), saved TXT strings, mail headers, and timestamps. The checklist helps ensure consistent evidence collection before contacting receivers or making DNS changes.

Continue with Amazon SES Account-Level Suppression: How to Use It for the next step in the workflow.

Related RepMail guides

• DKIM Multiple Signatures: Which Signature Can Satisfy DMARC?
• ARC Chain Validation Failure: Find the First Broken Instance

Sources