Summary
The need to set up DMARC for subdomains hinges on various factors, primarily whether the subdomain sends email. By default, subdomains inherit the parent domain's DMARC policy, but this can lead to issues if you need differing policies for subdomains. If a subdomain sends email, it *must* have its own DMARC record for authentication and protection against spoofing. If it doesn't send email, a `p=reject` policy is recommended. Subdomain policies (`p=`) take precedence over the top-level domain's subdomain policy (`sp=`), and `sp=` applies to subdomains lacking explicit policy records. Using subdomains to isolate sending reputation necessitates individual DMARC setups. Also, the reasons for having a subdomain can be the exception where granular DMARC control is needed such as for tool-specific verification, DNS template constraints or shared DNS control. Finally DMARC needs working SPF and DKIM implementations.
Key findings
- Default Inheritance: Subdomains inherit the parent domain's DMARC policy by default, which may be undesirable for certain configurations.
- Sending Subdomains Require DMARC: Subdomains sending email *must* have their own DMARC records for proper authentication and spoofing protection.
- Non-Sending Subdomains Benefit from `p=reject`: Subdomains not sending email should implement a DMARC record with a `p=reject` policy.
- Policy Precedence: Subdomain policies (`p=`) override top-level domain subdomain policies (`sp=`).
- `sp=` Application: `sp=` is relevant when subdomains do not publish policy records.
- Reputation Isolation Needs DMARC: Subdomains used for isolating sending reputation require individual DMARC setups.
- Specific cases: Specific cases where granular DMARC control is needed such as for tool-specific verification, DNS template constraints or shared DNS control.
- DMARC Prerequisites: DMARC setup relies on correctly configured SPF and DKIM records.
Key considerations
- Assess Subdomain Function: Determine whether each subdomain sends email or not.
- Consider Policy Differences: Assess whether subdomains need DMARC policies different from the parent domain.
- Implement Appropriate DMARC Records: Create DMARC records with appropriate policies (`p=none`, `p=quarantine`, `p=reject`) for each subdomain.
- Monitor DMARC Reports: Monitor DMARC reports to identify and address any authentication issues.
- Test Before Implementing: It is best practice to test your DMARC configuration on the main domain before implementing it on the subdomains.
- Reputation Isolation: Consider using subdomains to isolate sender reputation for marketing and transactional emails and apply a separate DMARC setup to each subdomain.
- Evaluate tool: Evaluate whether your tool has a need for DMARC.
- Evaluate DNS control: Evaluate whether you have full DNS control.
- DMARC Prerequisites: Check that you have SPF and DKIM fully implemented and correctly configured first.
What email marketers say
8 marketer opinions
Whether you need to set up DMARC for subdomains depends on several factors. By default, subdomains inherit the parent domain's DMARC policy unless a specific policy is defined for the subdomain. If a subdomain sends email, it generally requires its own DMARC record to ensure proper authentication and protection against spoofing. If a subdomain does not send email, a DMARC record with a `p=reject` policy is recommended to prevent unauthorized use. Subdomain policies (`p=`) take precedence over the top-level domain's subdomain policy (`sp=`), and `sp=` is relevant for subdomains without published policy records. Subdomains are often used to isolate sending reputation (e.g., transactional vs. marketing emails), necessitating individual DMARC configurations. If you want to handle email for a subdomain differently than the parent domain, then it requires its own DMARC record.
Key opinions
- Inheritance: Subdomains inherit the parent domain's DMARC policy by default.
- Sending Activity: Subdomains sending email should have their own DMARC records.
- Non-Sending Subdomains: Subdomains not sending email should have a `p=reject` DMARC policy.
- Policy Precedence: Subdomain policies (`p=`) override top-level domain subdomain policies (`sp=`).
- sp= Usage: `sp=` is applicable when subdomains lack explicit policy records.
- Isolation: Subdomains used for isolating sending reputation require individual DMARC setups.
- SPF/DKIM Prerequisite: Ensure proper SPF and DKIM setup before implementing DMARC.
Key considerations
- Subdomain Usage: Determine whether each subdomain sends email or not.
- Policy Differences: Assess if subdomains require DMARC policies different from the parent domain.
- DMARC Record Creation: Create DMARC records with appropriate policies (`p=none`, `p=quarantine`, `p=reject`) based on subdomain usage and desired security level.
- Monitoring: Monitor DMARC reports to identify and address any authentication issues.
- Testing: Test your DMARC implementation on the main domain before applying it to subdomains.
- Subdomain Reputation: Consider using subdomains to isolate sender reputation for marketing and transactional emails.
- DMARC Aggregation: If individual management is too difficult then you can inherit DMARC from the main domain. But this is not advised.
Marketer view
Marketer from Email Geeks answers the question by stating `sp=` is for subdomains that don’t publish policy records.
6 Dec 2021 - Email Geeks
Marketer view
Marketer from Email Geeks clarifies that subdomains are covered by the top-level domain's DMARC settings. Setting up separate DMARC for subdomains is only necessary if the subdomain's policy differs from the top-level domain.
10 Jul 2022 - Email Geeks
What the experts say
3 expert opinions
Implementing DMARC at the subdomain level is situation-dependent. It is beneficial when tools require exact subdomain DMARC checks, when lacking control over the entire domain's DNS or policy, or when using DNS templates without customization. Although some sources don't directly address subdomain DMARC setup, they highlight the importance of DMARC, SPF, and DKIM for comprehensive brand protection and deliverability, implying subdomain DMARC setup is a best practice.
Key opinions
- Tool Requirements: Some tools may necessitate DMARC checks at the specific subdomain level.
- Limited Control: Subdomain DMARC is useful when full domain DNS control is absent.
- DNS Templates: DMARC at the subdomain level is appropriate when using DNS templates that are not customized.
- Brand Protection: Complete brand protection and deliverability benefit from DMARC implementation, implying it is required for subdomains.
- SPF/DKIM Prerequisite: DMARC requires properly configured SPF and DKIM records to function effectively.
Key considerations
- Tool Compatibility: Check if your email-related tools require DMARC checks at the subdomain level.
- DNS Control: Assess your control over the entire domain's DNS settings.
- Policy enforcement: Understand the impact of not using a DMARC policy.
- DNS Customization: Determine if DNS template customization is feasible or desired.
- SPF/DKIM configuration: Check that you have correctly configured SPF and DKIM records
- Brand Reputation: Check whether brand reputation matters to your business and take action to protect it.
Expert view
Expert from Spam Resource shares that while the site doesn't explicitly answer the question 'Do I need to set up DMARC for subdomains?', it offers extensive information on DMARC implementation, implying that if subdomains send email, setting up DMARC for them is best practice. It emphasizes the importance of DMARC for brand protection and deliverability across the entire domain ecosystem which include subdomains.
1 May 2025 - Spam Resource
Expert view
Expert from Word to the Wise does not explicitly answer if you need to set up DMARC for subdomains on the given page, but it provides information on DMARC. It states that for DMARC to work correctly, it needs proper SPF and DKIM to be setup first. Suggesting that to fully protect your brand the implementation would be needed on all subdomains.
10 Dec 2022 - Word to the Wise
What the documentation says
3 technical articles
According to email authentication documentation from Google, DMARC.org, and Microsoft, setting up DMARC for subdomains is crucial. Each subdomain should ideally have its own DMARC record. Subdomains that send email *must* have their own DMARC record to ensure proper handling and prevent issues arising from inheriting the parent domain's policy. For subdomains that *do not* send email, a DMARC record with a `p=reject` policy is highly recommended to prevent spoofing and unauthorized use.
Key findings
- Individual Records: Each subdomain should ideally have its own DMARC record.
- Sending Subdomains: Subdomains sending email must have their own DMARC record.
- Non-Sending Subdomains: Subdomains not sending email should use a `p=reject` DMARC policy.
- Policy Inheritance: Without a dedicated DMARC record, subdomains inherit the parent domain's policy, potentially causing unintended consequences.
- Spoofing Prevention: `p=reject` helps prevent spoofing by indicating that no email should originate from the subdomain.
Key considerations
- Inventory: Identify all subdomains associated with your domain.
- Sending Status: Determine which subdomains send email and which do not.
- Record Creation: Create DMARC records for each subdomain, ensuring the correct policy is applied (either specific policies for sending subdomains or `p=reject` for non-sending subdomains).
- Policy Choice: Consider the implications of your DMARC policy choice (none, quarantine, reject) for each subdomain.
- Monitoring: Monitor DMARC reports to assess effectiveness and identify any issues.
- Authentication: Ensure authentication methods (SPF and DKIM) are setup correctly for mail coming from your domain and subdomains.
Technical article
Documentation from DMARC.org shares that DMARC policies apply to subdomains. If a subdomain sends email, it should have its own DMARC record. If a subdomain doesn't send email, create a DMARC record with `p=reject` to prevent spoofing.
6 Oct 2024 - DMARC.org
Technical article
Documentation from Microsoft advises that if a subdomain sends email, it must have its own DMARC record. If it doesn't, it is still affected by the parent domain's DMARC record. Also to set up a 'reject' record for all subdomains that do not send email.
20 Feb 2024 - Microsoft
Do DMARC and BIMI require p=reject to be present on the organizational domain?
Do subdomains need their own DMARC records if the main domain has one?
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 implement BIMI for multiple brands with subdomains?
How do I implement DMARC with BIMI on multiple subdomains?
How do I set up DMARC records for subdomains?
Should I add an explicit DMARC record for subdomains?
