How do DMARC records on subdomains override root domain DMARC policies?
Updated on 14 Aug 2026: We updated this guide to explain RFC 9989 tree walk behavior and how subdomain records redirect DMARC reports.
A DMARC record on a subdomain overrides the root domain only when that subdomain record is the policy record found for the visible From domain being evaluated. If mail uses user@x.example.com and _dmarc.x.example.com exists, that subdomain record wins over _dmarc.example.com.
If mail uses user@a.x.example.com, a plain record at _dmarc.x.example.com does not automatically control it. Under legacy RFC 7489 discovery, receivers checked the exact From domain and the organizational domain. RFC 9989 adds DNS Tree Walk queries, but an intermediate record is applied only when discovery identifies it as the organizational domain. With the records used below, _dmarc.example.com remains the policy record for the deeper child.
- Exact match: a valid record at the exact visible From domain takes priority over the root record.
- No exact record: the receiver finds the organizational domain with its supported discovery method and applies that record's sp, np, or p policy.
- Safe control: publish a record at each active From domain when that domain needs a guaranteed separate policy.
The lookup rule that matters
DMARC policy selection starts with the domain in the visible From header, technically the RFC5322.From domain. It does not start with the SPF return-path, the DKIM signing domain, or the sending IP. SPF and DKIM still matter because DMARC needs at least one passing, aligned authentication result, but the policy lookup key is the visible From domain.
This is why DMARC monitoring needs to inventory every visible From domain, not just the root domain. A root record can be correct and a subdomain can still be weaker because someone published a local record with p=none. A subdomain can also be stricter than the root, which is useful for transactional or app mail with a smaller sending surface.
Policy lookup is not sender lookup
A message sent by a marketing platform, billing system, or internal relay still uses the visible From domain for DMARC policy lookup. The sending system can be completely different, but the policy source comes from the From domain's DMARC discovery path.
The practical question is simple: what domain appears after the @ in the visible From address, and which DMARC policy record does discovery select for that domain?
The example in plain English
Take this setup. The root domain has sp=reject. The subdomain x.example.com also has a DMARC record, but it does not include sp=reject. The question is whether the root sp=reject protects a deeper child such as a.x.example.com.
Root DMARC recordDNS
_dmarc.example.com. 300 IN TXT ( "v=DMARC1; p=none; sp=reject; " "rua=mailto:dmarc@example.com" )
Subdomain DMARC recordDNS
_dmarc.x.example.com. 300 IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc@example.com" )
For mail with From user@x.example.com, the subdomain's own record applies and the effective policy is p=none. The root's sp=reject does not override a valid exact-domain DMARC record.
For mail with From user@a.x.example.com, both RFC 7489 and RFC 9989 use the root record with the DNS records shown. Legacy discovery skips the intermediate record. RFC 9989 queries _dmarc.x.example.com during the tree walk, but querying it does not make it the selected policy record. Because x.example.com has no psd=n, example.com remains the organizational domain and its sp=reject policy applies.
|
|
|
|
|---|---|---|---|
x.example.com | Yes | x.example.com | Subdomain p |
a.x.example.com | No | example.com | Root sp |
a.x.example.com | Yes | a.x.example.com | Child p |
a.x.example.com, x has psd=n | No | x.example.com | x sp, or x p if sp is absent |
Common outcomes for root and child DMARC policy lookup.
Why the sp tag is not a blanket override
The sp tag is the policy for existing subdomains of an organizational domain or Public Suffix Domain. It tells receivers what to do with mail that fails DMARC when an existing subdomain has no exact record. For a deeper explanation of the tag itself, see the sp tag page.
The sp tag changes the requested handling after DMARC fails. It does not change SPF or DKIM identifier alignment. The aspf and adkim tags control relaxed or strict alignment.
Root policy
- Scope: covers the root domain with p and its subdomains with sp when no exact record applies.
- Fallback: if sp is absent, existing subdomains use p; np can set policy for non-existent subdomains.
- Risk: a local subdomain record with p=none weakens that exact From domain.
Subdomain record
- Scope: wins for mail using that exact visible From domain.
- Child domains: its sp tag is ignored for deeper children unless discovery makes it an organizational domain.
- Control: use it when a subdomain has separate senders, ownership, or enforcement timing.
The trap is thinking of sp as universal inheritance. RFC 9989 uses it only after discovery identifies an organizational domain or PSD record. If x.example.com must become the organizational domain for itself and its descendants, psd=n declares that boundary for RFC 9989 receivers. Explicit records on active From domains remain the compatibility-safe choice.
Current standard versus legacy behavior
The now-obsoleted RFC 7489 discovery model used the Public Suffix List to determine the organizational domain. In that model, policy lookup usually involved at most two DMARC records: the exact visible From domain and the organizational domain. Intermediate records were not part of the normal lookup path.
RFC 9989 is the May 2026 Standards Track DMARC specification and obsoletes RFC 7489 and RFC 9091. It replaces Public Suffix List dependency with DNS Tree Walk behavior and uses active tags such as np, t, and psd. Aggregate reporting is defined in RFC 9990, and failure reporting is defined in RFC 9991. The tag registry marks np, psd, and t as active, while pct, rf, and ri are historic. RFC 9990 reports can identify the discovery method as psl or treewalk, which helps explain differing results during adoption. For a basic primer on default subdomain coverage, see subdomain defaults.
Under RFC 9989, psd=n states that a DMARC record is published for a domain that is not a Public Suffix Domain and is the organizational domain for itself and its subdomains. In the worked example, adding psd=n to the record on x.example.com would make that record applicable to a.x.example.com for RFC 9989 receivers.
Flowchart showing DMARC policy lookup starting at the visible From domain.
Standards transition
Publish explicit DMARC records for every active visible From domain that needs its own policy. This avoids relying on different receiver discovery methods when a child domain must behave differently from the root.
How to configure subdomains safely
A simple rule works well: if a domain appears in the visible From address, give it an intentional DMARC decision. It can inherit the root policy, but that inheritance should be documented and tested.
- Inventory: list every visible From domain used by product mail, marketing mail, support mail, and internal systems.
- Decide policy: choose whether each sending domain inherits the root policy or needs its own DMARC record.
- Keep reports: include rua on every selected policy record that should produce aggregate reports, then send those reports into one review workflow.
- Validate DNS: check for duplicate records, invalid tag values, omitted p tags, and unauthorized external report destinations.
- Stage changes: start with reporting, verify real traffic, then move high-confidence domains to enforcement.
Before changing a subdomain record, use a DMARC checker to confirm the exact DNS name, parsed tags, and policy value. This catches the common mistake where the intended record was created at the wrong DNS label.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If the checker shows a valid record at the exact From domain, expect that record to take priority for that domain. If it shows no record, confirm the organizational-domain fallback and decide whether an explicit child record is clearer.
A subdomain record also changes reporting
A separate subdomain record replaces more than the policy value. When that record is selected, its rua tag determines where aggregate reports go. The root record's rua does not inherit independently. If the selected subdomain record omits rua, receivers must not generate aggregate reports for that policy domain.
Copy the central reporting address into each explicit child record when one team needs complete visibility. Use a different address when a contractor or separate business unit owns the subdomain, but document the handoff so activity does not disappear from the main review process.
Authorize external report destinations
If the reporting address uses a different organizational domain, RFC 9990 requires the destination to authorize the policy domain with a DNS TXT record. The authorization name includes the domain where the selected DMARC policy was published, so adding a child record can require a corresponding child-specific authorization. Without it, receivers must ignore that external rua URI.
A safer DNS pattern
Most organizations should use a strict root policy for unused subdomains and explicit records for active sending subdomains. This keeps broad protection at the root while giving each real sending domain a clear owner.
Root record for broad protectionDNS
_dmarc.example.com. 300 IN TXT ( "v=DMARC1; p=reject; sp=reject; np=reject; " "rua=mailto:dmarc@example.com" )
Explicit record for an active child domainDNS
_dmarc.mail.example.com. 300 IN TXT ( "v=DMARC1; p=quarantine; " "rua=mailto:dmarc@example.com" )
The root record requests rejection for failed DMARC on the root, existing child domains without exact records, and non-existent child domains. The child record lets mail.example.com use quarantine while its authentication is being fixed or staged. When creating a fresh policy, a DMARC generator helps avoid syntax errors before the record reaches DNS.
The policy should match real mail
Do not set a child domain to reject until reports show that its legitimate mail passes DMARC through aligned SPF or DKIM. Enforcement without report review is how legitimate mail gets blocked.
Where Suped fits in the workflow
Suped's product supports this workflow by finding visible From domains in aggregate reports, checking the selected policy for each domain, and turning authentication failures into specific DNS or sender fixes. That matters when the root looks protected but an active subdomain still has p=none, omits rua, or points reports at an unauthorized destination.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Use the domain inventory and record diagnostics to compare root and child policies, then confirm the result against source-level mail flow. With hosted DMARC, a team can stage approved policy changes without requesting another manual DNS edit for every step toward enforcement.
The practical value is seeing the policy domain, report destination, authentication result, and sending source together. That evidence shows whether a child override is intentional or an unowned gap.
When an override is the right choice
A subdomain override is appropriate when the subdomain has its own sending model or rollout schedule, especially when a separate team owns it. It is risky when someone adds it only to enable reporting and leaves the policy weaker than the root.
|
|
|
|---|---|---|
Marketing mail | Own record | Separate sender |
App mail | Own record | Separate fixes |
Unused children | Root sp | Reject spoofing |
MSP client | Own record | Clear owner |
Use explicit subdomain records where ownership or risk differs.
The cleanest policy model is straightforward: the root protects the broad domain, each active sender domain has an intentional record, and aggregate reports confirm the policy before enforcement changes.
Views from the trenches
Best practices
Map every visible From domain before changing root policy, then test exact DMARC lookup paths.
Publish explicit DMARC records for active subdomains when their sending risk is different.
Keep root p, sp, np, and reporting addresses consistent so fallbacks behave predictably.
Common pitfalls
Assuming an intermediate subdomain record always controls deeper child domains causes gaps.
Leaving a subdomain at p=none while the root is at reject weakens that exact From domain.
Changing DNS without report review hides broken SPF, DKIM, or reporting destinations fast.
Expert tips
Use separate reporting views for root and subdomain traffic before moving to enforcement.
Name each sender source clearly so a later subdomain override has an owner and a reason.
Recheck DNS after each provider migration because stale records keep weaker policy active.
Marketer from Email Geeks says an exact From-domain DMARC record wins, so a subdomain record changes handling for mail using that same From domain.
2024-02-01 - Email Geeks
Marketer from Email Geeks says legacy discovery checks the exact From domain and the organizational domain, not every label between them.
2024-02-01 - Email Geeks
Practical answer
A subdomain DMARC record overrides the root policy for that subdomain's own visible From mail. It does not automatically control every deeper child domain just because RFC 9989 queries it during DNS Tree Walk.
For the example with root sp=reject and a subdomain record on x.example.com, the local record controls mail from x.example.com, while the root sp=reject controls a.x.example.com with the records shown. Publish an exact record for the deeper child when it needs a guaranteed separate policy across receiver implementations. This also gives reporting and incident-response work a clear policy owner.
