Summary
DMARC policies are fundamental for email deliverability, providing clear instructions on how recipient servers should handle unauthenticated emails from a domain. When a DMARC record is established for an organizational domain using the 'p' tag, its policy automatically extends to all subdomains that do not have their own specific DMARC records. However, organizations can refine this default behavior using the 'sp' tag within the organizational domain's DMARC record to apply a different, distinct policy to all its subdomains. Crucially, any individual subdomain can publish its own DMARC record, which will always override inherited policies or those set via the 'sp' tag, offering granular control. This hierarchical structure allows for flexible and comprehensive DMARC policy management across an organization's entire email sending infrastructure, from main domains to various subdomains used for different purposes.
Key findings
- Default Inheritance: By default, a DMARC policy published for an organizational domain (via the 'p' tag) applies to all its subdomains. Subdomains will inherit this policy unless an explicit override is present.
- 'sp' Tag Functionality: The 'sp' tag within the organizational domain's DMARC record allows for specifying a distinct DMARC policy that applies specifically to all subdomains, overriding the default 'p' policy for them.
- Subdomain Record Precedence: An explicitly published DMARC record for a specific subdomain will always take precedence over any inherited DMARC policies from the organizational domain, including those defined by the 'p' or 'sp' tags.
- Policy Control Tags: DMARC policies are primarily controlled by the 'p' tag for the organizational domain and the 'sp' tag for subdomains. If the 'sp' tag is omitted, subdomains will inherit the policy set by the 'p' tag.
- Organizational Domain Terminology: In the context of email authentication, 'example.com' is correctly termed the 'organizational domain' rather than the 'root domain,' serving as the primary point for DMARC policy application.
Key considerations
- Comprehensive Protection: Setting DMARC on the organizational domain is crucial for protecting the entire organization. The ultimate goal should be to establish DMARC across all active and inactive subdomains to prevent various forms of domain misuse.
- Phased Implementation: A recommended approach for DMARC rollout is to start with 'p=none' and 'sp=none' policies. This initial monitoring phase helps gather data and identify any legitimate email streams that might be impacted, especially those from third-party senders, before moving to stricter policies like 'quarantine' or 'reject'.
- Tailored Subdomain Policies: Subdomains often require different, and sometimes stricter, DMARC policies than the organizational domain. The 'sp' tag provides a convenient way to apply a separate policy to all subdomains, or individual subdomain records can be published for highly specific needs.
- Third-Party Sender Alignment: For organizations utilizing third-party services that send emails from subdomains, it is essential to ensure proper DMARC alignment. This can be achieved either through policy inheritance from the organizational domain or by explicitly publishing DMARC records for those specific subdomains.
- Flexible Policy Management: The combination of 'p=' and 'sp=' policies allows for effective coverage of an organizational domain and its various subdomains. This flexibility is vital for managing diverse email streams, such as transactional, marketing, and operational communications, while maintaining strong email authentication.
What email marketers say
12 marketer opinions
Establishing DMARC policies strategically ensures comprehensive email protection across an organization's entire domain ecosystem. While the 'p' tag in the organizational domain's DMARC record sets the default policy for the main domain and its subdomains, further refinement is possible through the 'sp' tag. This 'sp' tag allows a distinct DMARC policy to be applied to all subdomains collectively, offering a broad override to the general inheritance. For ultimate precision, individual subdomains can publish their own DMARC records, which always take precedence over any policies set at the organizational level, whether inherited or specified by the 'sp' tag. This hierarchical structure enables organizations to manage diverse email sending practices, such as those for transactional or marketing purposes, with specific and effective authentication rules.
Key opinions
- Domain and Subdomain Scope: A DMARC policy set at the organizational domain, through its 'p' tag, automatically governs all email sent from that domain and any subdomains lacking their own DMARC records. This establishes a baseline of protection for the entire domain hierarchy.
- sp Tag for Collective Subdomain Policy: The optional 'sp' tag within an organizational domain's DMARC record provides a mechanism to apply a distinct DMARC policy across all its subdomains. This allows for a global subdomain policy different from the main domain's 'p' policy, preventing them from simply inheriting the 'p' policy.
- Subdomain Record Precedence: Any DMARC record explicitly published for a specific subdomain will always take precedence over policies inherited from the organizational domain, including those set by the 'p' tag or the 'sp' tag. This allows for granular, subdomain-specific authentication rules.
- Strategic Policy Combination: The effective use of both 'p=' and 'sp=' policies enables a comprehensive DMARC strategy, efficiently covering an organizational domain and its various subdomains which might be used for different purposes like transactional or marketing emails.
- Centralized Protection Goal: While temporary subdomain DMARC setup can be useful, the overarching goal should be to establish DMARC on the organizational domain to ensure maximum protection across the entire email sending infrastructure, encompassing all active and inactive subdomains.
Key considerations
- Organizational Domain Control: Ideally, DMARC should be set up on the organizational domain to provide a foundational layer of protection for the entire entity. While starting with a subdomain DMARC can be a temporary measure, the ultimate aim is to secure the primary domain.
- Phased Implementation Strategy: It is advisable to initiate DMARC deployment with 'p=none' and 'sp=none' policies. This monitoring phase is crucial for gathering data, identifying legitimate email streams, and mitigating potential issues with third-party senders before escalating to stricter enforcement policies like 'quarantine' or 'reject'.
- Customizing Subdomain Policies: Subdomains often serve distinct purposes, such as transactional or marketing emails, and may therefore require DMARC policies different from, and sometimes stricter than, the main organizational domain. The 'sp' tag or individual subdomain records facilitate this customization.
- Covering All Domain Assets: A critical aspect of DMARC implementation is ensuring that all active and inactive subdomains are under a defined DMARC policy. This comprehensive coverage is essential to prevent various forms of domain spoofing and phishing attacks that could exploit unprotected subdomains.
- Managing Third-Party Complexity: Implementing DMARC, especially across subdomains, can become complex when relying on third-party senders. Careful consideration and coordination are necessary to ensure proper DMARC alignment and avoid deliverability issues for emails sent through these services.
Marketer view
Marketer from Email Geeks explains that if DMARC is set for an organizational domain, it applies to all mail sent from that domain and any subdomains that do not have their own records. If DMARC is set at the subdomain, it will only apply to that specific subdomain.
19 May 2023 - Email Geeks
Marketer view
Marketer from Email Geeks confirms the application of DMARC from the organizational domain to subdomains and introduces the `sp=` tag, which allows for different policies for subdomains. He notes that while it's ideal to own the organizational domain, often this is not the case, making things more complex. He also suggests that subdomains may often require different, typically stricter, DMARC policies than the organizational domain.
8 Sep 2021 - Email Geeks
What the experts say
2 expert opinions
DMARC policies are precisely defined using specific tags within the DNS record. The 'p=' tag dictates the policy for the organizational domain, while the 'sp=' tag is designed for subdomains. If the 'sp=' tag is not explicitly included, subdomains will by default inherit the policy set for the organizational domain via the 'p=' tag. This structured approach helps ensure consistent email authentication across an organization's entire domain space, effectively preventing unauthorized use of its sending domains and subdomains.
Key opinions
- Organizational Policy: The 'p=' tag in a DMARC record explicitly defines the policy that applies to the organizational domain itself.
- Subdomain Policy: The 'sp=' tag is specifically used to set the DMARC policy for all subdomains under the organizational domain.
- Default Inheritance: If the 'sp=' tag is absent from the DMARC record, subdomains automatically inherit the DMARC policy defined by the 'p=' tag of the organizational domain.
- Unified Authentication: The combination of 'p=' and 'sp=' policies ensures a consistent and unified authentication posture across the main domain and its subdomains, preventing unauthorized email sending.
Key considerations
- Holistic Domain Protection: Organizations must consider both 'p=' and 'sp=' tags to achieve comprehensive DMARC protection across their entire domain and subdomain ecosystem.
- Preventing Domain Misuse: Properly configuring 'p=' and 'sp=' tags is crucial for preventing spoofing and unauthorized use of both organizational domains and their subdomains.
- Clarity in Policy Application: Explicitly setting 'sp=' avoids ambiguity, ensuring that subdomains adhere to a specific intended policy rather than simply defaulting to the organizational domain's policy.
Expert view
Expert from Spam Resource explains that DMARC policies are set through the 'p=' tag (none, quarantine, reject) which applies to the organizational domain, and the 'sp=' tag, which specifically dictates the policy for subdomains. If 'sp=' is not set, the subdomain policy defaults to the organizational domain's 'p=' policy. This ensures consistent authentication across a domain and its subdomains, preventing unauthorized use of email sending from those domains.
1 Oct 2021 - Spam Resource
Expert view
Expert from Word to the Wise explains that a DMARC policy for an organizational domain is set using the 'p=' tag, with options like 'none', 'quarantine', or 'reject'. For subdomains, a separate policy can be defined using the 'sp=' tag. If the 'sp=' tag is omitted in the DMARC record, the subdomains will inherit the policy specified by the 'p=' tag of the organizational domain. This provides flexibility for organizations to manage authentication enforcement across their entire domain space.
31 Jan 2023 - Word to the Wise
What the documentation says
5 technical articles
DMARC policy application within an organization's domain structure follows a clear hierarchy. A DMARC record established for the organizational domain generally extends its policy to all subdomains by default. This default behavior can be modified using the 'sp' tag within the organizational domain's DMARC record, allowing for a distinct policy to be applied specifically to all subdomains. Most importantly, any DMARC record explicitly published for a specific subdomain will always take precedence over any inherited or 'sp' tag policies from the parent domain. This layered approach ensures flexible and robust control over email authentication across an organization's entire email sending infrastructure.
Key findings
- Policy Inheritance: A DMARC policy published for an organizational domain will apply to all its subdomains by default, unless those subdomains have their own explicit DMARC records.
- 'sp' Tag Override: The 'sp' tag within an organizational domain's DMARC record can be used to specify a different DMARC policy that applies specifically to all its subdomains, overriding the default inheritance of the 'p' tag policy.
- Subdomain Record Precedence: An explicit DMARC record published directly for a specific subdomain will always take precedence over any inherited policies from the organizational domain, including those set by the 'p' or 'sp' tags.
- Policy Tags 'p' and 'sp': The 'p' tag defines the DMARC policy for the organizational domain, and the 'sp' tag defines the policy for subdomains. If 'sp' is absent, subdomains inherit the 'p' policy.
- Controlling Sending Reputation: DMARC policies are crucial for controlling an email sender's reputation, ensuring that emails sent from both main domains and subdomains are properly authenticated.
Key considerations
- Granular Control: The combination of inherited policies, the 'sp' tag, and explicit subdomain records provides administrators with granular control over DMARC policies across their entire domain infrastructure.
- Third-Party Alignment: Organizations using third-party services that send emails from subdomains must ensure proper DMARC alignment, either through policy inheritance or by establishing specific DMARC records for those subdomains.
- Avoiding Ambiguity: Clearly defining DMARC policies for subdomains, either via the 'sp' tag or individual records, is vital to avoid ambiguity and ensure consistent email authentication.
Technical article
Documentation from DMARC.org explains that a DMARC policy published for an organizational domain applies to all its subdomains by default, unless a subdomain explicitly publishes its own DMARC record. The 'sp' tag within the organizational domain's DMARC record can be used to specify a different policy for subdomains.
12 Dec 2023 - datatracker.ietf.org
Technical article
Documentation from Google Workspace Admin Help clarifies that a DMARC record is published for a specific domain, and its policy typically applies to that domain and its subdomains. Administrators can use the sp tag to define a separate policy for subdomains or create individual DMARC records for specific subdomains if needed.
19 Jul 2021 - support.google.com
Do I need to set up DMARC for subdomains?
How do DMARC policies and RUA/RUF settings inherit or override each other between a domain and its subdomains?
How do DMARC records on subdomains override root domain DMARC policies?
How do I set up DMARC records for subdomains?
How does DMARC policy application work with subdomains and CNAME records?
How does the DMARC sp tag affect subdomain policies?
