How do DMARC records on subdomains override root domain DMARC policies?
Updated on 22 Oct 2026: We clarified subdomain policy overrides, DNS setup, and the authentication impact of psd=n under RFC 9989.
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 has a valid DMARC record, 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 or an applicable Public Suffix Domain (PSD). 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 discovers the applicable organizational-domain or PSD record and uses its np, sp, or p policy as appropriate.
- Safe control: publish a record at each active From domain when that domain needs a separate policy across discovery methods.
How receivers select a subdomain DMARC policy
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 or internal relay still uses the visible From domain for DMARC policy lookup. For example, with From user@news.example.com and a custom MAIL FROM of bounce.example.com, policy discovery starts at _dmarc.news.example.com, not _dmarc.bounce.example.com. The custom MAIL FROM domain is used for SPF authentication.
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?
Example: root sp=reject and subdomain p=none
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 | p=none on x.example.com |
a.x.example.com | No | example.com | sp=reject on example.com |
a.x.example.com | Yes | a.x.example.com | The child's own p value |
a.x.example.com, x has psd=n (RFC 9989) | No | x.example.com | x sp, or p=none if sp is absent |
Policy lookup with the records shown; the psd=n row applies only to RFC 9989 discovery.
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: existing subdomains use sp, then p if sp is absent. Non-existent subdomains use np, then sp, then p.
- Risk: a local subdomain record with p=none weakens that exact From domain when the inherited policy was stricter.
Subdomain record
- Scope: wins for mail using that exact visible From domain.
- Child domains: its sp tag affects deeper children only if discovery selects it as an organizational-domain or applicable PSD record.
- 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.
RFC 9989 DNS tree walk versus legacy discovery
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 discovery. RFC 9990 defines aggregate reporting, including the optional discovery_method field with values psl or treewalk. Where present, this field identifies which discovery method the receiver used. For 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.
DMARC policy discovery flowchart showing an exact From-domain lookup followed by fallback when no record is found.
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.
Check authentication before adding psd=n
Adding psd=n changes the organizational-domain boundary used for relaxed SPF and DKIM alignment, as well as policy discovery. RFC 9989 requires the authenticated domain and visible From domain to share an organizational domain for relaxed alignment.
Applying that rule to the example, adding psd=n at x.example.com means a passing DKIM signature with d=example.com no longer satisfies relaxed DKIM alignment for From user@a.x.example.com. The From domain now has x.example.com as its organizational domain, while the signing domain has example.com. DMARC still passes if another passing SPF or DKIM result satisfies alignment.
Check shared DKIM signing domains and custom MAIL FROM domains before declaring this boundary. For a separate policy on one From domain, an exact DMARC record avoids declaring a new organizational boundary.
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: publish one DMARC TXT record per name, put v=DMARC1 first, use valid policy values, and authorize 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.
For mail.example.com, publish a TXT record at _dmarc.mail.example.com. In a DNS zone for example.com, the host field is usually _dmarc.mail; in a delegated zone for mail.example.com, it is usually _dmarc. Check whether the DNS provider appends the zone name. A separate DNS zone is not required just to publish DMARC.
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.
Include p explicitly. RFC 9989 treats an omitted p in an otherwise valid record as p=none; RFC 7489 requires p. Duplicate DMARC records are not combined, and a malformed record does not guarantee fallback to the root policy.
Allow cached DNS answers to expire according to the previous record's TTL, then check authoritative DNS and receiving systems again. Publishing a record does not instantly replace cached policy values.
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.
When a subdomain inherits the root record, its traffic can already appear in reports sent to the root rua address. A separate subdomain record is not required just to collect those reports.
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.
The selected record also supplies aspf and adkim. If a child record omits those tags, their default is relaxed alignment; strict settings on the root record are not carried into it.
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 child-specific authorization unless an applicable wildcard already authorizes it. Without authorization, receivers must ignore that external rua URI.
Example DNS records for separate enforcement
Use strict inherited policies for non-sending subdomains after checking active senders. The example below also sets root p=reject, so it fits a non-sending root or a controlled mail stream validated for enforcement. RFC 9989 advises against p=reject for general-purpose mail domains whose users send to mailing lists.
Example root record after enforcement reviewDNS
_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. Include forwarding and mailing-list traffic in that review because indirect delivery can break authentication. The policy is a requested handling preference; receiving systems make the final delivery decision.
Where Suped fits in the workflow
Suped is our DMARC reporting and email authentication platform. Use its aggregate reports and DNS diagnostics to compare visible From domains with their selected policies and investigate authentication failures. Check DNS alongside reports: without an authorized rua destination delivering to Suped, traffic will be missing from its report views.
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.
Subdomain DMARC checks in practice
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.
Frequently asked questions
Yes. If the applicable organizational-domain record has no sp tag, its p policy applies to existing subdomains that have no exact DMARC record. For non-existent subdomains, np takes priority; if np is absent, receivers use sp, then p if sp is also absent.
It replaces the root sp policy for mail using that exact subdomain as the visible From domain. With the example records, a deeper child without an exact record still uses the root sp policy.
No. The selected DMARC policy record supplies the rua destination. If an explicit subdomain record omits rua, receivers must not generate aggregate reports for that policy domain.
No. Unused subdomains can inherit a strict root sp or np policy. Active sending subdomains need explicit records when they require separate reporting, ownership, or staged enforcement.
Publish a DMARC record at the exact visible From domain, include the intended reporting destination, and verify real mail before moving to reject.
RFC 7489 uses the Public Suffix List for organizational-domain discovery, while RFC 9989 uses DNS Tree Walk. Check which method the receiver or checker implements. RFC 9990 aggregate reports can identify it through the optional discovery_method field, using psl or treewalk. Explicit records reduce policy-selection ambiguity.
