Summary
When a DMARC record is published on a subdomain, it overrides the subdomain policy (`sp`) set on the parent or organizational domain for that specific subdomain and any sub-sub-domains, unless those sub-sub-domains define their own DMARC records. This means that a more specific DMARC record always takes precedence. For instance, if your root domain has a sp=reject policy, but a subdomain has its own DMARC record (even if it's p=none and no sp tag), the root domain's sp=reject will not apply to that subdomain's sub-sub-domains. The presence of the subdomain's DMARC record interrupts the inheritance chain from the root. This is a crucial aspect of DMARC implementation that affects email deliverability and security for complex domain structures.
Key findings
- Direct override: A DMARC record published directly on a subdomain takes precedence over the sp (subdomain policy) tag from the root or organizational domain. This means that if a subdomain has its own DMARC record, the parent's sp policy is ignored for that subdomain.
- Inheritance interruption: The existence of a DMARC record on a subdomain effectively stops the inheritance of the root domain's sp policy for any sub-sub-domains of that specific subdomain. For example, if test.com has sp=reject, but x.test.com has its own DMARC record (even without an sp tag), then test.com's sp=reject will not apply to a.x.test.com.
- Fallback for sub-sub-domains: If a sub-sub-domain, such as a.x.test.com, does not have its own DMARC record, the system will look to its immediate parent (x.test.com) for guidance. If x.test.com's record does not specify a subdomain policy via an sp tag, then no DMARC policy from x.test.com will explicitly apply to a.x.test.com.
Key considerations
- Policy management complexity: As your domain structure becomes more complex with multiple subdomains and sub-sub-domains, managing DMARC policies can become challenging. Each specific DMARC record published breaks the chain of inheritance from higher-level domains.
- DMARC record placement: You must carefully consider where to place your DMARC records to ensure the correct policies are applied. Placing a DMARC record on a subdomain essentially makes it authoritative for that subdomain and its children (if an sp tag is used). Learn more about best practices for DMARC record placement for subdomains.
- Understanding sp tag: The sp tag within a DMARC record is specific to subdomains of the domain where the record is published. If present, it dictates the policy for those subdomains, unless they have their own DMARC records. For a deeper dive, review this guide on understanding DMARC and subdomains.
- Avoiding unintended policies: Incorrect DMARC record setup, especially concerning sp tags and subdomain records, can lead to unintended 'reject' or 'quarantine' policies being applied to legitimate email traffic, resulting in significant deliverability issues. This is why it's vital to understand DMARC policy inheritance.
What email marketers say
Email marketers often encounter scenarios where DMARC policies on subdomains seem to behave differently than expected, particularly when a root domain has a strict policy like sp=reject. Their discussions frequently highlight the confusion surrounding how a subdomain's DMARC record, even a seemingly lenient one, can interrupt the stricter policy inheritance from the parent domain. Many realize that the presence of *any* DMARC record on a subdomain changes how its sub-sub-domains are evaluated.
Key opinions
- Subdomain precedence: Marketers frequently observe that a DMARC record on a subdomain will always override any sp policy set by the root domain. This means that if x.test.com has a record, test.com's sp policy is not considered for x.test.com.
- Sub-sub-domain behavior: There's common confusion about whether a root domain's sp policy extends to sub-sub-domains if the intermediate subdomain has its own DMARC record without an sp tag. The consensus indicates that the intermediate subdomain's record breaks this deeper inheritance.
- Seeking external validation: Marketers often rely on DMARC checking tools or AI-driven insights to confirm their understanding of these complex DMARC inheritance rules, as the specifics can be counter-intuitive.
Key considerations
- Careful DMARC setup: When setting up DMARC for multiple subdomains, it's crucial to understand that each subdomain can have an independent policy, which will override the root's sp tag. This requires careful planning to avoid accidental email blocking (getting on a blocklist or blacklist, for example). Explore DMARC best practices.
- Impact on deliverability: Incorrectly configured subdomain DMARC records can lead to legitimate emails being rejected or quarantined, significantly impacting email deliverability. This is especially true for marketing or transactional emails sent from specific subdomains.
- Understanding the p tag: The primary p tag on a subdomain's DMARC record applies to that specific subdomain. If no sp tag is present in that record, then its sub-sub-domains might not inherit any explicit DMARC policy from that subdomain. This DMARC record guide for subdomains offers more insight.
Marketer view
A marketer from Email Geeks states that the DMARC record published directly on a subdomain will always override the policy (p tag) set by the root domain or the subdomain policy (sp tag) of its parent. This direct override is a fundamental aspect of DMARC inheritance.
Marketer view
A user from Quora suggests that by default, the DMARC policy defined for an organizational domain will apply to all its subdomains. However, this inheritance is broken if a specific DMARC record is published for that particular subdomain.
What the experts say
Email deliverability experts emphasize that DMARC policy inheritance is not a simple cascade down the domain tree. While the sp tag from a root domain applies to its direct subdomains in the absence of a specific DMARC record, the presence of *any* DMARC record on an intermediate subdomain will interrupt that inheritance for its children. Experts also point out the distinction between the current DMARC specification and future iterations like DMARCbis, which may simplify the lookup process.
Key opinions
- Direct lookup: Experts confirm that DMARC checks primarily look for a record on the 'From:' domain itself. If one exists, that record's policy applies. If not, the system then checks the organizational domain's DMARC record. Intermediate records are not considered in a continuous tree walk under the current specification.
- Inheritance termination: The presence of a DMARC record on a subdomain (`x.test.com`) stops the inheritance of the sp policy from the root domain (`test.com`) for sub-sub-domains (`a.x.test.com`). This is true even if the subdomain's record itself does not include an sp tag.
- Current vs. future DMARC: While the current DMARC specification uses the Public Suffix List (PSL) to determine the organizational domain, future revisions (DMARCbis) are expected to adopt a more explicit tree-walk approach for resolving policies. Both methods are likely to coexist for some time.
Key considerations
- Understanding the organizational domain: It's essential to correctly identify the organizational domain, as its DMARC policy applies as a fallback. Tools and the Public Suffix List aid in this determination. For more, see our guide on DMARC policies for organizational and subdomains.
- Policy application: The DMARC policy is applied based on the most specific record found for the 'From:' domain. If no record is found for the exact 'From:' domain, the policy from the organizational domain's DMARC record is used. Nothing in between.
- Mitigating risks: To prevent unintended 'reject' or 'quarantine' actions, particularly for sub-sub-domains, ensure that DMARC records are explicitly set where needed, or that the policies of intermediate subdomains are clearly defined (or are intentionally absent) to avoid unexpected inheritance breaks. Understand how to safely transition your DMARC policy.
- Stay updated on specifications: With the evolution of DMARC specifications, such as DMARCbis, it's important for experts and domain owners to stay informed about changes in how policies are resolved and applied across complex domain structures. Regularly consult official DMARC documentation or reputable sources like NsLookup.io's DMARC guide.
Expert view
An expert from Email Geeks clarifies that currently, DMARC policies derive the organizational domain using the Public Suffix List (PSL). However, in the future, DMARCbis will adopt a full tree-walk method, and both approaches will likely be in use for a transitional period.
Expert view
An expert from Word to the Wise notes that DMARC records are typically published using the label "_dmarc" directly under the root of the domain. This is the standard location for DMARC policy declarations.
What the documentation says
Official DMARC documentation and related specifications confirm that a DMARC record published on a specific domain (e.g., a subdomain) is the most authoritative policy for that domain. The sp tag within a parent's DMARC record governs subdomains only if those subdomains do not have their own explicit DMARC records. The presence of such a record on a subdomain explicitly breaks the inheritance chain from higher-level domains for that branch of the domain tree.
Key findings
- Explicit subdomain record precedence: DMARC documentation specifies that if a domain has its own DMARC record, that record's policy (`p` tag) and subdomain policy (`sp` tag) will apply, overriding any inherited `sp` policy from a higher-level domain.
- Subdomain policy (`sp`) scope: The sp tag in a DMARC record (`_dmarc.example.com`) dictates the policy for its subdomains (`sub.example.com`) only when those subdomains do not have their own DMARC record (`_dmarc.sub.example.com`).
- Inheritance termination: The presence of a DMARC record on a subdomain acts as a terminating point for policy inheritance from the parent domain's sp tag. This means even if the subdomain's record has no sp tag, it stops the root's sp from affecting its own children.
Key considerations
- Policy lookup mechanism: The DMARC specification mandates that receiving mail servers first check for a DMARC record on the exact domain in the RFC5322.From header. If absent, they then check the organizational domain, not necessarily intermediate domains, for policy guidance.
- Public Suffix List (PSL) importance: The PSL plays a critical role in determining the organizational domain, which is essential for understanding DMARC fallback policies. This list helps prevent unintended policy application for public suffixes.
- Future DMARC developments: The DMARCbis working group is exploring alternative DMARC policy discovery mechanisms, including a pure DNS tree-walk, which might simplify some of the current inheritance complexities. However, current implementations still adhere to the existing specification. The Klaviyo Help Center has information on email authentication.
Technical article
The DMARC specification (RFC 7489) details that if a DMARC record is found for the RFC5322.From domain, that record’s policy is applied. If no record is found, then the DMARC policy for the Organizational Domain is considered, as defined by the Public Suffix List.
Technical article
DMARC.org documentation confirms that the 'sp' tag within a DMARC record specifies the policy for subdomains. This policy only takes effect if a specific subdomain does not have its own unique DMARC record published in DNS.
Related resources
9 resources
Related pages
DMARC policies for organizational domains and subdomains explained
What is the best practice for DMARC record placement for subdomains?
How do DMARC policies and RUA/RUF settings inherit or override each other between a domain and its subdomains?
List of DMARC tags and their meanings
DMARC record and policy examples
The benefits of implementing DMARC
A simple guide to DMARC, SPF, and DKIM
How to safely transition your DMARC policy to quarantine or reject
Understanding and troubleshooting DMARC reports from Google and Yahoo
How to fix common DMARC issues in Microsoft 365 and Google Workspace
