Do subdomains inherit DMARC policy?

Yes. A subdomain with no DMARC policy record of its own can be covered by an applicable parent policy discovered through DMARC's DNS Tree Walk. For an existing subdomain, the parent record's sp value applies when present; otherwise its p value is used. For a non-existent subdomain, np can apply before fallback to sp or p. An explicit valid DMARC record at the Author Domain takes precedence for that domain. SPF does not use this inheritance model.
Quick takeaways
- A subdomain does not always need its own DMARC record.
- An explicit record at the Author Domain is evaluated first.
- sp can set handling for existing subdomains.
- np can set handling for non-existent subdomains under current DMARC.
- Without an applicable override, p provides the fallback handling preference.
This diagram summarizes the article's diagnostic sequence. Use the linked standards, current provider documentation, and production evidence for exact decisions. Open the full-size diagram.
Who is affected?
This matters to domains that send from marketing or transactional subdomains and to owners protecting unused names from spoofing. It also matters when different teams control DNS at different levels.
DMARC policy applies to the visible From domain. Review the DMARC overview for authentication and alignment before treating subdomain policy as a standalone control.
What are the requirements?
Receivers first look for a DMARC policy at the exact Author Domain. When none is found, RFC 9989 defines a bounded DNS Tree Walk that can discover an applicable organizational or public-suffix policy.
If the applied policy record belongs above an existing Author subdomain, the sp tag supplies the subdomain handling preference when present. If sp is absent, p applies. For a non-existent subdomain, np can supply the preference; otherwise the receiver falls back through sp and p as defined by the standard.
An explicit record at _dmarc.sub.example.com can state the policy for mail From sub.example.com. It must still be one valid record, and the subdomain's real senders need aligned SPF or DKIM.
When does the requirement take effect?
The discovery process runs for each message's Author Domain. DNS caching means a new explicit record or changed parent tag may reach receivers at different times until TTLs expire.
RFC 9989 is the current protocol reference. The np tag and current tree-walk rules should be checked before copying assumptions from older DMARC guidance.
How do I implement the requirement?
1. Inventory visible From domains
List the organizational domain, active sending subdomains, parked names, and delegated DNS zones. Use message and aggregate evidence rather than a guessed inventory.
2. Choose the parent defaults
Set p for the policy domain and decide whether existing or non-existent subdomains need different sp or np handling.
3. Add explicit records only for intentional differences
Publish a subdomain record when that Author Domain needs its own policy, reporting, or staged rollout. Avoid creating hundreds of identical records without an operational reason.
4. Authenticate each active sender
Configure aligned SPF and DKIM for every application using a subdomain in From. Policy inheritance does not create authentication.
How do I validate compliance?
Query the exact subdomain policy location, then follow the current discovery path to the applicable parent. Confirm p, sp, or np produces the intended handling. Send through active sources and review aggregate reports by header_from domain.
Use Palisade's DNS lookup tool to inspect the hierarchy and Email Security Score for public configuration. Reports remain necessary for rarely used subdomains.
Frequently asked questions
Keep going with AI
Ask AI how this applies to you
Take this guide to your assistant — each question opens pre-filled, with a link back to this page so it can read the details.

Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →


