Should I add an explicit DMARC record for subdomains?

Key findings

• Inheritance: By default, a subdomain inherits the DMARC policy (specifically the sp= tag) from its organizational domain. This means an explicit record isn't strictly necessary for enforcement if sp=reject is set at the top level.
• Clarity and Intent: Adding an explicit DMARC record to a subdomain, even if identical to the inherited policy, clearly indicates that the subdomain is intended for email sending and has a deliberate DMARC policy.
• Maintainability: Explicit records can improve the long-term maintainability of your DMARC setup, making it easier to manage and understand individual subdomain policies.
• Reporting Discrepancies: Some DMARC reporting tools may inconsistently honor or even miss reports from subdomains relying solely on inherited sp= policies, potentially leading to incomplete data.
• Policy Overrides: An explicit subdomain DMARC record allows for a different policy than the organizational domain, which is crucial for specific use cases like email marketing subdomains that might need a less strict policy initially.

Key considerations

• Subdomain Use: Consider if the subdomain actively sends email or if it's primarily used for other purposes. If it sends email, an explicit record is generally beneficial for clarity and control.
• Policy Consistency: Decide whether all subdomains should adhere to the same DMARC policy as the organizational domain, or if some require a custom policy. For more detail, see our guide on DMARC policies for organizational domains and subdomains.
• Reporting Granularity: Evaluate the importance of receiving accurate and consistent DMARC reports for each subdomain. Explicit records can ensure better reporting.
• Impact on Deliverability: While p=reject is strong, ensure all legitimate mail sources for subdomains are properly authenticated with SPF and DKIM to avoid deliverability issues. TechTarget provides a good overview of how SPF, DKIM, and DMARC work together.
• Complexity vs. Control: Weigh the added complexity of managing more DMARC records against the increased control and clarity they provide.

Key opinions

• Inheritance as Default: Many marketers initially assume the organizational domain's sp=reject policy sufficiently covers subdomains, based on the DMARC specification.
• Strategic Subdomain DMARC: Explicit subdomain DMARC records are considered beneficial when the subdomain is actively used for mail, even if the policy is the same, as it signifies intentional email use.
• DMARC-Unfriendly Streams: Some marketers advocate for disabling DMARC (or setting a less strict policy) on specific subdomains used for email marketing, as DMARC's design can inadvertently block legitimate, aligned marketing messages due to recipient-side configurations.
• Reporting Challenges: A key concern is that some DMARC report generators might not reliably process or provide consistent data for subdomains that rely solely on inherited sp= policies.
• Quantifying Risk: While it's hard to quantify revenue loss from DMARC blocking legitimate marketing emails, marketers understand the importance of quantifying the risk of their dedicated marketing subdomains being spoofed if DMARC isn't properly applied.

Key considerations

• Impact on Deliverability: Marketers must carefully weigh the security benefits of a strict DMARC policy against potential impacts on the deliverability of their marketing campaigns. This includes understanding why emails might go to spam.
• Reporting Accuracy: Consider the need for granular DMARC reports for each subdomain. Inconsistent reporting can hinder efforts to monitor and optimize email performance. Vircom's blog explains how DMARC records facilitate reports.
• Subdomain Strategy: Develop a clear strategy for how each subdomain will be used for email sending and configure DMARC accordingly, which may involve explicit records for specific purposes.
• Policy Alignment: Ensure that any explicit subdomain DMARC records align with overall brand security and email strategy, even if they deviate from the top-level domain's policy.

Key opinions

• Explicit Records for Active Subdomains: It is generally considered good practice to add an explicit DMARC record for any subdomain actively used for sending email, even if its policy would be inherited.
• Enhanced Clarity: An explicit record makes it clear that a subdomain is intended for email and has a specific DMARC policy, rather than merely inheriting one.
• Improved Maintainability: Having distinct records for sending subdomains can simplify DMARC management over time, reducing ambiguity.
• Organizational Context Matters: The optimal DMARC setup for subdomains heavily depends on the organization's specific email sending infrastructure and goals.
• Policy Overrides as Necessary: Creating a specific subdomain DMARC record is essential when a different policy (e.g., p=none) is required for certain mail streams or platforms, which the inherited sp= cannot provide.

Key considerations

• Active Subdomain Use: If a subdomain is actively sending email, an explicit DMARC record enhances the clarity and intentionality of its policy. For further information, see our guide on the best practice for DMARC record placement for subdomains.
• Policy Differentiation: Consider if any subdomains require a policy different from the organizational domain. This is common when using third-party senders for specific email types.
• Reporting Reliability: Be aware that some DMARC reporting systems may be less reliable for subdomains relying solely on inherited policies. This could affect the accuracy of your DMARC reports from Google and Yahoo.
• Long-Term Management: Explicit records can streamline the long-term management and auditing of DMARC settings across a complex domain structure. Word to the Wise offers insights into DMARC implementation and best practices.

Key findings

• Default Inheritance: If no explicit DMARC record is found for a subdomain, its policy is inherited from the organizational domain via the sp tag in the organizational DMARC record.
• Explicit Overrides: A DMARC record published directly on a subdomain will override any inherited policy from the organizational domain, allowing for specific policy settings.
• Purpose of sp tag: The sp tag provides a way to apply a different policy to subdomains than the primary domain without requiring individual records for every subdomain.
• Reporting Scope: DMARC reports (RUA and RUF) are generated based on the policy applied to the specific domain or subdomain from which the email purports to originate.

Key considerations

• Policy Granularity: Use explicit subdomain DMARC records when granular policy control is needed, allowing different policies for different subdomains based on their email sending roles.
• Avoiding Unintended Consequences: Carefully consider the implications of a strict sp=reject policy on subdomains that might be used by third-party senders not fully aligned. This is crucial for understanding how DMARC policy application works with subdomains.
• Simplifying Setup: For subdomains not sending email, relying on the inherited sp=reject policy simplifies DNS management and provides default protection. You can explore a comprehensive guide to using different DMARC records for subdomains.
• Monitoring and Auditing: Regular DMARC reporting is essential to monitor policy effectiveness, regardless of whether policies are inherited or explicitly set for subdomains.