How do DMARC records on subdomains override root domain DMARC policies?
Updated on June 11, 2026: We refreshed the DMARC standard references for RFC 9989, RFC 9990, and RFC 9991, including current tag status for np, psd, t, pct, rf, and ri. 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, do not assume the record at _dmarc.x.example.com controls it. Under legacy RFC 7489 discovery, receivers checked the exact From domain and then the organizational domain, not every intermediate label. The May 2026 RFC 9989 standard adds DNS Tree Walk behavior, but many receivers and reports still include older behavior during transition. I treat explicit DMARC records on active From domains as the safest operating model.
- Exact match: a valid record at the exact visible From domain takes priority over the root record.
- No exact record: the receiver falls back according to its supported DMARC discovery method.
- Safe control: publish a record at each sending From domain when that domain needs its own 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, matching 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. The opposite also happens: a subdomain can be stricter than the root, which is useful for transactional mail, app mail, or a domain that has 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 therefore simple: what domain appears after the @ in the visible From address, and where is the first applicable DMARC policy record 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, the answer depends on receiver discovery support. Under RFC 7489 style discovery, the receiver does not use the intermediate _dmarc.x.example.com record for that deeper child. If there is no exact record at _dmarc.a.x.example.com, the organizational domain record at _dmarc.example.com is the fallback.
|
|
|
|
|---|---|---|---|
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 |
Common outcomes for root and child DMARC policy lookup.
Why the sp tag is not a blanket override
The sp tag is the subdomain policy for a DMARC record's applicable policy domain. It tells receivers what to do with mail from subdomains that fail DMARC when those subdomains do not have their own applicable policy record. For a deeper explanation of the tag itself, see the sp tag page.
Root policy
- Scope: covers the root domain with p and subdomains with sp when no stronger match exists.
- Fallback: if sp is absent, subdomains use the p policy.
- 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: deeper labels need explicit testing because receiver discovery differs.
- Control: use it when a subdomain has separate senders or separate risk.
The trap is thinking of sp as a universal inheritance setting. It is a policy preference used after discovery finds the applicable policy record. That distinction explains why a record on x.example.com does not automatically become the answer for every name under x.example.com.
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. That improves how complex domain structures are discovered, but it also means reports and receiver behavior can differ while adoption catches up. For a basic primer on default subdomain coverage, see subdomain defaults.
Under RFC 9989, psd=n can tell discovery that an intermediate DMARC record is published for a domain that is not a Public Suffix Domain but is the organizational domain for itself and its subdomains.
Flowchart showing DMARC policy lookup starting at the visible From domain.
Standards transition
The safest operational answer is to publish explicit DMARC records for every active visible From domain. That avoids relying on receiver-specific discovery behavior when a child domain has a different policy than the root.
How to configure subdomains safely
I use a simple rule: if a domain appears in the visible From address, treat it as a domain that needs an intentional DMARC decision. That decision can be inherited root policy, but it should not be accidental.
- 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: send aggregate reports for root and child records into one place so policy gaps are visible.
- Validate DNS: check for duplicate records, invalid tag values, missing p values, and broken 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 which fallback policy real receivers are reporting and decide whether an explicit child record is cleaner.
A safer DNS pattern
For most organizations, I prefer a strict root policy for unused subdomains and explicit records for active sending subdomains. This keeps the root domain protective 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 blocks failed DMARC for the root and unused child domains. The child record lets mail.example.com run a different policy while it 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 SPF or DKIM result passes DMARC matching. Enforcement without report review is how good mail gets blocked.
Where Suped fits in the workflow
Suped's product is built for this exact workflow: finding which visible From domains are sending, checking whether each domain has a valid policy, and turning raw aggregate reports into fixes a team can act on. That matters when the root looks protected but one active subdomain still has p=none or a broken report address.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For this problem, Suped is the best overall fit for most teams because it combines DMARC reporting, hosted policy management, hosted SPF, SPF flattening, blocklist (blacklist) monitoring, alerts, and guided repair steps in one workflow. With hosted DMARC, a team can stage policy changes without asking for repeated DNS edits every time a subdomain moves closer to enforcement.
The useful part is not only validating the TXT record. The useful part is seeing source-level mail flow, policy mismatches, failing authentication, and subdomain records in one place so the decision is based on real traffic.
When an override is the right choice
A subdomain override is right when the subdomain has a different sending model, different owner, or different rollout schedule. It is risky when someone adds it only to get reporting working 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 boring: root protects the broad domain, each active sender domain has an intentional record, and reports prove 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 safely prove control over every deeper child domain unless the relevant discovery method and DNS records make that policy applicable.
For the example with root sp=reject and a subdomain record on x.example.com, the local record controls mail from x.example.com. For a.x.example.com, publish an explicit DMARC record if you need a guaranteed separate policy. That is the clean answer for operations, audits, and incident response.
