What is the best practice for DMARC record placement for subdomains?
Michael Ko
Co-founder & CEO, Suped
Published 28 Jun 2025
Updated 19 Aug 2025
6 min read
When implementing DMARC, a common question arises regarding how to best handle subdomains. Should you rely on a single DMARC record at your organizational domain, or should you create specific records for each subdomain? This decision impacts your email security, deliverability, and administrative overhead.
The core of the issue lies in DMARC's hierarchical nature. By default, a DMARC record published on a main domain, like example.com, also applies to its subdomains, such as marketing.example.com or mail.example.com, unless explicitly overridden. This inheritance can simplify setup but may not always provide the granular control needed for diverse email sending practices.
Getting DMARC record placement right for subdomains is crucial for maintaining brand reputation and ensuring legitimate emails reach their intended inboxes. A misconfigured DMARC setup can lead to legitimate emails being blocked or marked as spam, impacting your communication efforts and business operations.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, builds upon SPF and DKIM to provide a comprehensive framework for email authentication. It allows domain owners to specify how receiving mail servers should handle emails that fail authentication checks, and it provides a reporting mechanism to monitor email streams. You can learn more with a simple guide to DMARC, SPF, and DKIM.
For subdomains, DMARC offers two primary approaches for policy application: inherited policies and explicit policies. The inherited policy is the default, where the DMARC record of the organizational domain (e.g., example.com) automatically applies to all its subdomains. This is convenient for domains that do not send emails from their subdomains or have a consistent sending policy across all of them.
Example DMARC record for organizational domainDNS
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarcreports@example.com"
An explicit policy, on the other hand, involves creating a separate DMARC record directly on a subdomain, such as _dmarc.marketing.example.com. This overrides the inherited policy from the organizational domain, allowing you to set a unique DMARC policy for that specific subdomain. This flexibility is often necessary for larger organizations or those using various third-party sending services.
The `sp=` tag versus explicit records
A key DMARC tag that influences subdomain policy is sp, which stands for subdomain policy. This tag, when included in your organizational domain's DMARC record, allows you to specify a DMARC policy for all subdomains that do not have their own explicit DMARC record. This provides a centralized way to manage subdomain policies without creating individual records for each.
DMARC record with `sp=` tagDNS
_dmarc.example.com. IN TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:dmarcreports@example.com"
Understanding how the `sp` tag affects policies is critical. When sp= is defined, any subdomain without its own explicit DMARC record will inherit the policy specified by sp=, not the p= policy of the organizational domain. This distinction is vital for preventing unintended consequences.
Using the `sp=` tag
Centralized control: Manage policies for all subdomains from a single DMARC record on the main domain.
Simplicity: Reduces administrative complexity, especially for domains with many subdomains.
Default protection: Ensures a baseline policy (e.g., p=quarantine) is applied to all subdomains by default, even those not actively sending email.
Using explicit subdomain records
Granular control: Set unique policies for specific subdomains, allowing different email flows to have different DMARC enforcement.
Isolation: A strong policy (e.g., p=reject) on a specific subdomain does not affect other subdomains.
Flexibility: Ideal when using third-party email providers that require specific DMARC configurations for their sending domains.
While using sp= can simplify initial setup, it's essential to understand that an explicit subdomain DMARC record will always override the sp= policy from the parent domain. This hierarchical rule is defined in the DMARC specification.
Strategic placement for optimal security
The best practice for DMARC record placement depends largely on your email ecosystem and security goals. For most organizations, starting with a DMARC record at the organizational domain level is the recommended approach. This provides a foundational layer of protection that covers all subdomains by default, leveraging DMARC's inheritance feature.
Once a baseline organizational policy is in place (often starting with p=none for monitoring), you can then assess the need for more specific subdomain policies. This approach allows for a gradual and controlled DMARC deployment, minimizing the risk of disrupting legitimate email flows. More details can be found in DMARC policies for organizational domains.
Recommendation for most domains
Begin by deploying a DMARC record on your organizational domain (e.g., example.com) with p=none. Include a rua tag to receive aggregate reports. Monitor these reports to identify all legitimate sending sources across your main domain and subdomains. Consider using the sp= tag if you want a different default policy for subdomains from the outset, before explicitly defining subdomain records.
If you determine that specific subdomains have unique sending patterns, different third-party senders, or require stricter policies (e.g., p=reject), then publishing an explicit DMARC record for that subdomain is appropriate. This allows you to tailor the policy without affecting the main domain or other subdomains. For instance, a subdomain used for transactional emails might have a more lenient DMARC policy initially while a subdomain for marketing might aim for p=reject after careful monitoring.
Common scenarios and considerations
Understanding when to use the sp= tag versus explicit subdomain DMARC records is key. It's not a one-size-fits-all solution, as different scenarios call for different strategies. For a more detailed guide on various DMARC setups, explore DMARC record and policy examples.
Scenario
Best practice for DMARC placement
All subdomains use consistent sending practices or don't send email.
Publish a single DMARC record on the organizational domain with a p= policy that applies to all. The sp= tag can be set to the same policy as p= for clarity, or omitted if the p= policy is intended to cover subdomains by inheritance.
Specific subdomains use unique sending services or require different policies.
Publish an explicit DMARC record for each specific subdomain (e.g., _dmarc.marketing.example.com). This record will override the organizational domain's policy, including any sp= tag.
Unused subdomains that should not send email.
Ensure these subdomains either inherit a strong p=reject policy via the organizational domain's sp= tag, or publish an explicit DMARC record with p=reject on the subdomain itself.
The Microsoft documentation on DMARC clarifies that DMARC records automatically cover all subdomains unless an explicit subdomain record exists. This underscores the importance of a well-planned DMARC strategy that accounts for all your domains and subdomains.
It's also vital to monitor DMARC reports consistently, whether you are using inherited or explicit policies. These reports provide invaluable insight into your email ecosystem, revealing any legitimate emails that are failing authentication or attempts by malicious actors to spoof your domain or subdomains. Regular review allows you to refine your DMARC records and ensure proper authentication.
Ultimately, there is no single best practice for DMARC record placement for subdomains that fits every organization. The most effective strategy is one that aligns with your specific sending environment, security requirements, and administrative capabilities. Prioritize monitoring and iterative policy enforcement to ensure smooth email operations and strong brand protection.
Views from the trenches
Best practices
Always start with a DMARC record at the organizational domain, even if it's `p=none`.
Utilize the `sp=` tag to apply a default subdomain policy without needing individual records.
For specific subdomains with unique sending needs, create explicit DMARC records to override inheritance.
Monitor DMARC reports regularly to identify legitimate email sources and adjust policies.
Common pitfalls
Forgetting to account for all subdomains, leading to unauthenticated legitimate emails.
Applying a strict `p=reject` policy on the organizational domain without understanding `sp=` behavior.
Not monitoring DMARC reports, thus missing issues with legitimate sending or spoofing attempts.
Creating redundant DMARC records for subdomains when the organizational domain's policy suffices.
Expert tips
Consider a `p=none` policy on your root domain and then apply `sp=reject` for all subdomains. Then, create explicit subdomain records for any subdomains that actually send email with a `p=none` while you gain visibility.
For larger organizations with complex subdomain structures, a DMARC management platform can greatly simplify monitoring and policy adjustments.
Ensure DNS caching is considered when making changes to DMARC records, as propagation can take time.
Use different subdomains for different email sending purposes (e.g., transactional, marketing) to better manage reputation and DMARC policies.
Expert view
Expert from Email Geeks says they prefer the organizational domain to have a record, at least `p=none`, but notes that you can also publish subdomain specific policies that will act independently if they differ from the organizational domain.
May 15, 2019 - Email Geeks
Expert view
Expert from Email Geeks says that the best approach depends on your specific needs, particularly whether you administratively own the organizational domain.
May 15, 2019 - Email Geeks
Ensuring comprehensive domain protection
The choice between a DMARC record on the root domain with the sp= tag and explicit subdomain records isn't about one being inherently better than the other. It's about strategic alignment with your email sending architecture and risk tolerance. For a general overview of DMARC setup, including organizational and subdomain policies and reporting, refer to our guide on DMARC setup best practices.
Effective DMARC deployment for subdomains requires ongoing vigilance. Regularly review your DMARC reports, adapt your policies as your sending infrastructure evolves, and ensure that all legitimate email sources are properly authenticated. This proactive approach will strengthen your email security posture and improve deliverability across your entire domain landscape.
