How do DMARC records on subdomains override root domain DMARC policies?
Michael Ko
Co-founder & CEO, Suped
Published 27 May 2025
Updated 17 Aug 2025
10 min read
Understanding how DMARC (Domain-based Message Authentication, Reporting, and Conformance) policies interact across your main domain and its subdomains can be a nuanced topic. Many believe that a root domain's DMARC policy automatically extends to all subdomains, and while this is often true by default, explicit subdomain DMARC records can significantly change this behavior. The core principle revolves around how email receiving servers discover and apply these policies, prioritizing the most specific record available. This hierarchical structure is designed to give domain owners granular control over their email authentication settings.
I've often seen confusion arise when organizations manage multiple subdomains for different purposes, such as marketing, transactional emails, or internal communications. Each of these subdomains might have different sending patterns and require distinct DMARC policies to ensure proper email deliverability and prevent spoofing. It's crucial to grasp the exact rules of inheritance and override to avoid unintentional email rejections or deliverability issues. Let's delve into how this mechanism works.
The key to DMARC policy application is the lookup process. When a mail receiver gets an email, it looks for a DMARC record associated with the domain found in the email's 'From' header. This lookup follows a specific path, starting with the exact sending domain and potentially falling back to higher-level domains if no explicit record is found. This fallback mechanism is where the inheritance from the root domain comes into play.
By default, if a subdomain does not have its own DMARC record, it will inherit the policy from its organizational domain, typically the root domain. This is a foundational aspect of DMARC, designed to provide blanket protection across an entire domain space without requiring individual records for every single subdomain. For instance, if your root domain example.com has a DMARC record with a policy of p=quarantine, then mail.example.com will also operate under a quarantine policy if mail.example.com doesn't have its own record.
However, the DMARC specification includes a tag called sp. This optional tag, when present in a root domain's DMARC record, allows you to specify a different policy for all subdomains than the policy applied to the root domain itself. For instance, you could have p=none for your root domain but sp=quarantine for all subdomains. This provides flexibility, allowing you to monitor the main domain while taking action on subdomains, or vice-versa.
It's important to remember that the sp tag only applies to subdomains that do not have their own explicit DMARC record. The moment a subdomain publishes its own DMARC record, it takes precedence and overrides any inherited policy from the root, including the sp tag from the parent. This is critical for preventing unexpected email delivery failures or allowing unauthorized emails to pass through.
Understanding the DMARC lookup process
When an email arrives, the receiving server performs a DMARC lookup. This process primarily checks two locations for a DMARC record:
Exact Domain Lookup: The server first checks for a DMARC record at _dmarc.sendingdomain.com. If found, that record's policy (the p tag) applies to emails from sendingdomain.com.
Organizational Domain Fallback: If no explicit DMARC record is found for the exact sending domain, the receiver determines the organizational domain (often the root domain, like example.com for sub.example.com). It then checks the organizational domain's DMARC record. If this record contains an sp tag, that policy is applied to the subdomain. If there's no sp tag in the organizational domain's record, the p tag from the organizational domain applies to the subdomain instead.
When a subdomain DMARC record overrides
This is where the direct override comes into play. If your root domain, say yourdomain.com, has a DMARC record with sp=reject, this means any subdomain unless specified otherwise will have its non-compliant emails rejected. However, if you then create a specific DMARC record for mail.yourdomain.com with p=none, this new record for mail.yourdomain.com will take precedence. It completely overrides the sp=reject from the root domain for that specific subdomain.
The RFC 7489, which defines DMARC, clearly states that DMARC records published at child domains explicitly override extant parent policies. This means the most specific DMARC record always wins. If you have _dmarc.sub.example.com and _dmarc.example.com, the policy on sub.example.com will be used. This allows for tailored policies without affecting the broader domain. For a deeper dive into the standard, refer to the DMARC RFC document on datatracker.ietf.org.
Root domain policy with 'sp' tag
You set a DMARC record on yourdomain.com that includes a subdomain policy.
Effect on sub.yourdomain.com: Policy is none. It overrides the root domain's sp=reject.
Handling sub-subdomains and complex hierarchies
The question often extends to deeper levels of subdomains. What happens if you have test.com with sp=reject, a subdomain x.test.com with its own DMARC record (e.g., p=none but no sp), and then a sub-subdomain a.x.test.com that has no DMARC record of its own? The most specific rule applies.
In this scenario, for an email sent from a.x.test.com, a DMARC-compliant receiving server would first look for a DMARC record directly at _dmarc.a.x.test.com. Since we assume none exists, it then identifies the organizational domain for a.x.test.com, which is test.com (based on the Public Suffix List). The DMARC record for test.com would then be consulted. Crucially, the presence of a DMARC record on x.test.com (even with p=none and no sp tag) effectively stops the inheritance chain for deeper subdomains from the root's sp policy. This means a.x.test.com would likely fall back to the root test.com's sp=reject policy. This can be complex, and I recommend reviewing how DMARC works with subdomains for further clarity.
The key takeaway is that the existence of a DMARC record on x.test.com acts as a 'break' in the inheritance chain from test.com's sp tag for its own subdomains. If x.test.com does not have an sp tag, then a.x.test.com effectively has no DMARC policy unless it publishes its own. This is a common pitfall that can lead to unexpected deliverability issues or security vulnerabilities if not configured correctly. For comprehensive guidance on DMARC policies and RUA/RUF settings, it's important to understand these specific interactions.
Beware of unmanaged sub-subdomains
If test.com has sp=reject, and x.test.com has its own DMARC record of p=none (without an sp tag), then a sub-subdomain like a.x.test.com (without its own DMARC record) will not inherit reject from test.com. It effectively has no explicit DMARC policy, which can be a security vulnerability.
Strategic DMARC deployment for subdomains
Given the intricacies of DMARC inheritance and overrides, a strategic approach to deploying DMARC across your domain ecosystem is essential. It's rarely a one-size-fits-all solution, especially for organizations with a complex web of subdomains. Start with a p=none policy on your root domain and monitor reports to understand your email traffic patterns before moving to more restrictive policies.
For each subdomain that sends email, I recommend evaluating whether it requires its own explicit DMARC record. If a subdomain has a unique sending infrastructure, a high volume of email, or is critical for your business operations, defining a separate DMARC policy for it provides greater control and visibility. This is particularly true if you want a different policy for that subdomain than what the root domain's sp tag would dictate. You can find out more about the DMARC sp tag and subdomain policies in our other guides.
The implementation should be iterative and data-driven, relying on DMARC reports to identify legitimate email sources and potential spoofing attempts. Don't rush to p=reject without thorough monitoring. A gradual transition allows you to identify and authorize all legitimate sending sources, preventing your own emails from ending up in spam folders or being blocked outright. This approach also helps avoid inadvertently putting your domain on a blocklist (or blacklist) due to misconfigurations.
Best practices for subdomain DMARC management
Managing DMARC for multiple subdomains requires careful planning and continuous monitoring. Here are some best practices I recommend to ensure effective email authentication and deliverability:
Audit regularly: Periodically review all your active subdomains and their DMARC configurations. Ensure that each subdomain either correctly inherits the desired policy or has an explicit record that aligns with its sending needs.
Explicit over implicit: When in doubt, or for critical sending subdomains, publish an explicit DMARC record. This eliminates ambiguity and ensures your desired policy is enforced, regardless of changes to the root domain's sp tag.
Monitor reports: Utilize DMARC reports (RUA and RUF) to gain visibility into email authentication results for all your domains and subdomains. This data is invaluable for identifying legitimate email streams that might be failing DMARC and for detecting potential spoofing attempts. You can learn more about understanding DMARC reports from Google and Yahoo.
Align SPF and DKIM: DMARC relies on SPF and DKIM. Ensure these authentication mechanisms are properly configured and aligned for all domains and subdomains that send email. Misconfigurations here are often the root cause of DMARC failures.
By following these practices, you can maintain a robust email security posture and maximize your email deliverability across your entire domain landscape.
Views from the trenches
Best practices
Always define a DMARC record on critical subdomains, even if it mirrors the root policy.
Use DMARC reports to guide your subdomain policy decisions before implementing stricter actions.
Implement a phased rollout for DMARC policies, starting with 'p=none' for monitoring.
Regularly review your Public Suffix List (PSL) entries, as they influence DMARC organizational domain identification.
Ensure SPF and DKIM records are correctly set for all sending subdomains to pass DMARC alignment.
Common pitfalls
Assuming root domain 'sp' tag applies universally, even when subdomains have their own DMARC records.
Forgetting to publish DMARC records for newly created subdomains used for email sending.
Not monitoring DMARC reports, leading to blind spots regarding subdomain email authentication failures.
Immediately moving to 'p=reject' on subdomains without sufficient data, causing legitimate emails to be blocked.
Misunderstanding how DMARC inheritance interacts with multiple levels of subdomains and explicit records.
Expert tips
A DMARC record on a subdomain acts as an explicit override; it immediately stops any inheritance from the root's 'sp' tag for that subdomain and its children.
The DMARC specification, particularly RFC 7489, is the definitive source for understanding policy application and overrides.
Future DMARC standards (DMARCbis) may introduce more granular subdomain policy features, but current behavior relies on explicit overrides and the 'sp' tag.
When troubleshooting, check the DMARC record of the exact sending domain first, then the organizational domain as defined by the Public Suffix List.
Always verify your DMARC configurations using a reliable DMARC record lookup tool to ensure expected behavior.
Expert view
Expert from Email Geeks says the subdomain's DMARC record will always override the root domain's policy, including the 'sp' tag.
February 1, 2024 - Email Geeks
Marketer view
Marketer from Email Geeks says DMARC checkers will go directly to the organizational domain if no record is found on the sending subdomain.
February 1, 2024 - Email Geeks
Final thoughts on subdomain DMARC management
The power of DMARC lies in its flexibility to define policies at various levels of your domain hierarchy. While default inheritance from the root domain provides a baseline, explicit DMARC records on subdomains offer precise control, enabling you to tailor authentication policies to the specific needs and risks associated with each subdomain. This granular control is vital for maintaining email security and optimizing deliverability.
Always prioritize clarity and precision in your DMARC configurations. If a subdomain is actively sending email, especially if it handles sensitive communications, ensure it has a well-defined DMARC record. This active management helps prevent unauthorized use of your domains (spoofing) and ensures that your legitimate emails reach their intended recipients without being caught in spam filters or blocklists (also known as blacklists).
Remember, DMARC is not a 'set it and forget it' solution. Consistent monitoring of your DMARC reports is essential to adapt your policies as your email sending patterns evolve. By staying proactive, you can safeguard your domain reputation and ensure reliable email communication.
