Should I add an explicit DMARC record for subdomains?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 May 2025
Updated 16 Aug 2025
8 min read
When setting up DMARC, a common question arises regarding subdomains: Do they need their own explicit DMARC records, or is the main organizational domain's record sufficient? The answer often depends on your sending practices and desired level of control.
By default, a DMARC record published on your organizational domain, say example.com, will apply to its subdomains like marketing.example.com, unless explicitly overridden. This inheritance is managed by the sp= tag in your root DMARC record, which specifies the policy for subdomains. For instance, if your main domain's record is v=DMARC1; p=reject; sp=reject;, all subdomains will also inherit a reject policy. This means that emails failing DMARC checks from any subdomain would be rejected by recipient servers.
While this inheritance can be convenient, relying solely on the root domain's sp= tag might not always be the best practice, especially if you send email from subdomains. An explicit DMARC record on a subdomain provides clearer intent and more granular control over its email authentication policy. This helps ensure that the subdomain is recognized as an intentional sender of email.
Explicit DMARC records for subdomains (e.g., _dmarc.marketing.example.com) offer several advantages over relying on the sp= tag from the organizational domain. Firstly, they provide undeniable clarity. An explicit record signals that the subdomain is intentionally configured for email sending and that its DMARC policy is purposeful, rather than just inherited. This can be important for receiver reputation systems.
Secondly, explicit records allow for a distinct policy, independent of the main domain's. If example.com has a p=reject policy, but you want marketing.example.com to use p=quarantine or p=none to gather more data or avoid immediate rejection, an explicit record allows this flexibility. This is particularly useful for email marketing platforms or transactional email services that might send on your behalf from a subdomain, where you might initially prefer a more relaxed policy.
For domains that do not send email, it's a best practice to publish an explicit DMARC record with a p=reject policy and no rua or ruf tags to prevent spoofing. This applies to subdomains as well, especially if they are not intended for email use.
Considerations and limitations
While publishing explicit DMARC records for subdomains offers granular control, it also introduces additional management overhead. Each subdomain you explicitly define needs its own DNS TXT record for DMARC. This can become cumbersome if you have a large number of subdomains, especially if many of them do not send email. However, for those that do send, the added clarity and control typically outweigh the effort.
A point of caution: some DMARC report generators may not consistently honor or process RUA (aggregate report URI) or RUF (forensic report URI) tags specified in subdomain-specific DMARC records. This could lead to missing or inconsistent reporting data for that specific subdomain, making it harder to monitor DMARC compliance and detect potential spoofing attempts. Always verify that your monitoring tools accurately process reports from explicit subdomain DMARC records.
The RFC 7489, which defines DMARC, notes that the sp tag is ignored for DMARC records published directly on subdomains. This means that if you have an explicit DMARC record for marketing.example.com, any sp tag within that specific subdomain's record will not have an effect. This behavior is detailed in the official DMARC specification, available from the IETF RFC 7489 documentation. It underscores that an explicit subdomain record is self-contained in its policy application.
How to implement explicit records
When deciding whether to add explicit DMARC records for subdomains, consider your overall email sending strategy. If a subdomain is actively used for email, such as transactional.example.com or newsletter.example.com, an explicit DMARC record is highly recommended. This allows you to tailor its policy (e.g., p=quarantine) and reporting to its specific use case, providing better visibility and control.
For subdomains that are not, and will never be, used for email, explicit records with a strict policy like p=reject can enhance your overall domain security. This helps prevent threat actors from spoofing these non-sending subdomains, which can be a common vector for phishing attacks. The Australian Cyber Security Centre (ACSC) recommends configuring explicit DMARC records for subdomains where you do not want the inherited policy to apply or where you want maximum protection against spoofing.
However, if you have hundreds or thousands of subdomains, and the vast majority do not send email and can simply inherit the root domain's sp=reject policy, then creating explicit records for all of them might be overkill and add unnecessary complexity. Prioritize explicit records for subdomains that actively send email, or those with critical brand implications that require specific DMARC handling. Knowing when to use an explicit record is a key part of best practices for DMARC setup.
When to use explicit DMARC for subdomains
Active sending: If a subdomain (e.g., mail.yourdomain.com) is used to send emails, an explicit DMARC record allows for precise policy control and reporting for that specific sending source.
Different policies: If a subdomain needs a different DMARC policy (e.g., p=quarantine or p=none) than the main domain’s inherited sp= policy, an explicit record is necessary. This is a common requirement, for example when setting up DMARC for BIMI.
Non-sending subdomains for security: To explicitly protect subdomains that should never send email, an explicit p=reject record ensures strict enforcement.
To explicitly set a DMARC record for a subdomain, you would create a TXT record at _dmarc.subdomain.yourdomain.com. This record would contain your desired DMARC policy for that specific subdomain. For example, if your main domain is example.com and you have a marketing subdomain marketing.example.com, you would add a record like this:
This explicit record for marketing.example.com would override any sp= tag from example.com, allowing you to implement a tailored DMARC policy. You can learn more about the specifics of DMARC tags and their meanings to further customize your records.
Managing your DMARC records
Inherited policy
Subdomains automatically inherit the sp= policy from the root organizational domain. This is simplest for domains not sending email.
Simplicity: Less DNS management for many subdomains, especially if not used for sending.
Default protection: If the root has a strong p=reject, sp=reject policy, all subdomains get this baseline security.
Explicit policy
A separate DMARC record is published directly on the subdomain (e.g., _dmarc.sub.domain.com), overriding the inherited policy. This is ideal for subdomains with active sending or unique needs.
Granular control: Allows for specific policies and reporting for individual subdomains, vital for deliverability.
Clarity: Clearly indicates that the subdomain is an intentional email sender.
Security for non-senders: Can implement a strict p=reject policy on specific non-sending subdomains to prevent spoofing.
Managing DMARC for subdomains is an ongoing process, not a one-time setup. Regularly reviewing your DMARC reports for both your root domain and any explicitly defined subdomains is crucial. This will help you identify any issues, such as legitimate emails being quarantined or rejected, or detect unauthorized sending from your subdomains. Tools for DMARC monitoring can greatly simplify this task, providing insights into your email traffic and helping you maintain optimal email deliverability.
Maintaining a healthy email sending reputation means proactively managing your DMARC implementation across all your domains and subdomains. Neglecting subdomains can create security vulnerabilities or lead to unexpected deliverability issues, potentially causing your emails to land in the spam folder or on an email blacklist (or blocklist). Regularly checking your DMARC records and adjusting policies as needed is a core part of a robust email security strategy.
Views from the trenches
Best practices
Always add an explicit DMARC record for any subdomain that actively sends email.
Use distinct DMARC policies for subdomains that have different sending purposes than your main domain.
For subdomains not used for email, publish an explicit DMARC record with p=reject for enhanced security.
Common pitfalls
Relying solely on the sp= tag for actively used subdomains can obscure their email intent.
Forgetting to update DMARC records when changing email service providers for a subdomain.
Assuming DMARC reporting works identically for inherited and explicit subdomain policies, leading to missed data.
Expert tips
Consider a phased approach, starting with p=none for new subdomain DMARC records to gather data before moving to quarantine or reject.
Utilize a DMARC record generator to ensure proper syntax for your subdomain records.
Integrate DMARC monitoring tools to get a consolidated view of all your domain and subdomain email traffic and DMARC compliance.
Expert view
Expert from Email Geeks says that if a subdomain sends mail, it is probably a good idea to add an explicit DMARC record for it, even if the policy would be inherited. This makes it clearer that the subdomain is intended to do email.
2021-09-14 - Email Geeks
Expert view
Expert from Email Geeks says that having an explicit DMARC record is more maintainable and provides clarity that the subdomain has an intentional DMARC policy, rather than merely relying on an inherited sp= policy.
2021-09-14 - Email Geeks
Make informed DMARC decisions for your subdomains
Deciding whether to add an explicit DMARC record for your subdomains comes down to balancing simplicity with control and security. While DMARC's inheritance mechanism simplifies initial setup, it's often prudent to deploy explicit records for subdomains that actively send email, or those you wish to explicitly protect from spoofing.
This approach provides clearer intent, allows for tailored policies, and enhances your overall domain security posture. Remember to always monitor your DMARC reports to ensure your policies are functioning as intended and to quickly address any deliverability issues or unauthorized activity.
