Setting up DMARC (Domain-based Message Authentication, Reporting, and Conformance) is crucial for protecting your brand and ensuring email deliverability. While many focus on the main domain, understanding how DMARC works with subdomains is equally vital. Many organizations use subdomains for various purposes, such as marketing campaigns (e.g., mail.yourdomain.com), transactional emails (e.g., alerts.yourdomain.com), or even internal communications.
Each of these subdomains can represent a unique sending identity, and without proper DMARC configuration, they could become entry points for phishing attacks or email spoofing. DMARC helps email receivers verify that incoming mail from your domain (or subdomain) is legitimate and aligns with your published SPF and DKIM records, which are the foundational authentication protocols.
This guide will walk you through the process of setting up DMARC records for your subdomains, detailing the technical steps and strategic considerations to ensure your email program is secure and effective.
DMARC policies are designed to be inherited. This means that if you have a DMARC record set up for your organizational (root) domain, its policy will generally apply to all subdomains by default, unless those subdomains have their own explicit DMARC records. For example, if your main domain is yourdomain.com, a DMARC record published at _dmarc.yourdomain.com will also cover sub.yourdomain.com. This inheritance mechanism is a foundational aspect of how DMARC works.
However, you often need more granular control over your subdomains. This is where the DMARC sp= (subdomain policy) tag comes into play. The sp= tag allows you to specify a different policy for all subdomains under a parent domain, distinct from the main domain's p= (organizational domain policy). This provides flexibility, especially when managing various email sending services that use different subdomains.
You might choose to use the sp= tag for convenience, or you might set up a dedicated DMARC record for a specific subdomain to override the inherited policy and the sp= tag if it exists. For a deeper dive into this, you can learn more about how the DMARC sp tag affects subdomain policies. Most email deliverability experts recommend explicit records for clarity and control when possible, as explored in the best practice for DMARC record placement for subdomains.
Understanding the sp= tag
The sp= tag is an optional but powerful DMARC tag. It allows you to specify a DMARC policy that applies only to subdomains, overriding the main p= policy for your root domain. This can be particularly useful if you have a strict policy on your main domain but need a more relaxed one for certain subdomains, or vice-versa.
Syntax: It follows the format sp=policy, where policy can be none, quarantine, or reject.
Example:v=DMARC1; p=reject; sp=none; rua=mailto:dmarc_reports@yourdomain.com This record applies p=reject to the organizational domain and sp=none to all subdomains under it.
Implementing DMARC for specific subdomains
To set up DMARC for a specific subdomain, you'll create a new TXT record in your DNS settings, similar to how you would for your main domain. This dedicated record for the subdomain will override any inherited policies from the parent domain or the sp= tag. This method provides the most precise control over each subdomain's email authentication behavior.
The key difference lies in the name (or host) field of the TXT record. For a subdomain like sub.yourdomain.com, the DMARC record would be published at _dmarc.sub.yourdomain.com. Your DNS provider's interface might require you to enter just _dmarc.sub in the name field, as the root domain is often appended automatically.
It's crucial that any subdomain for which you set a DMARC record also has correctly configured SPF and DKIM records, and that the emails sent from that subdomain achieve alignment with these records. Without proper SPF and DKIM authentication, your DMARC policy, regardless of its setting, cannot fully protect your subdomain or ensure deliverability. For detailed guidance on setting up these records, review our simple guide to DMARC, SPF, and DKIM.
After adding the TXT record, remember that DNS changes can take some time to propagate across the internet. This propagation period can vary, usually from a few minutes to several hours. You can verify your DMARC record's setup by using online DMARC lookup tools. For more information on this process, a helpful resource from Microsoft Learn provides guidance on configuring DMARC.
Strategic DMARC policies for subdomains
When deploying DMARC for subdomains, a phased approach is highly recommended. Always start with a policy of p=none. This none policy puts DMARC in monitoring mode, allowing you to receive DMARC reports (RUA and RUF reports) without affecting email delivery. These reports are invaluable for understanding your email ecosystem, identifying legitimate sending sources, and spotting potential unauthorized use of your subdomains. You can find simple DMARC examples using p=none.
Once you have a clear picture of your subdomain's email traffic and have ensured that all legitimate emails are correctly authenticating, you can gradually move to stricter policies like p=quarantine or p=reject. This transition helps to prevent spoofing and protect your subdomain's reputation. It's important to monitor DMARC reports constantly to avoid inadvertently impacting legitimate email delivery or ending up on a blocklist (or blacklist).
Starting with p=none
Visibility: Gain insight into all email traffic using your subdomain, both legitimate and fraudulent. Receive comprehensive DMARC monitoring reports.
No Impact: Emails that fail DMARC authentication are still delivered, allowing you to identify misconfigurations without interrupting your mail flow.
Transitioning to stricter policies
Protection:p=quarantine directs unauthenticated mail to spam, while p=reject blocks it entirely, effectively stopping spoofing.
Reputation: Prevents your subdomain from being associated with malicious activity, safeguarding your email deliverability and ensuring you don't get added to a blocklist (or blacklist). Keep an eye on your blocklist monitoring.
Implementing and maintaining DMARC for subdomains is an ongoing process. Regular review of your DMARC reports helps you adapt your policies as your email sending infrastructure evolves. This proactive approach ensures that all your sending domains, including subdomains, remain secure and trustworthy, minimizing the risk of email compromise and deliverability issues.
Views from the trenches
Best practices
Always align SPF and DKIM with your DMARC subdomain policy to ensure proper authentication and prevent spoofing.
Start with a DMARC policy of p=none for subdomains to gather reports and understand traffic before enforcing stricter policies.
Regularly review DMARC reports for all active and inactive subdomains to identify potential abuse or misconfigurations.
Common pitfalls
Forgetting that DMARC policies can inherit from the organizational domain, leading to unexpected email rejections for subdomains.
Not configuring SPF and DKIM correctly for each subdomain, which causes DMARC authentication failures.
Implementing a strict DMARC policy too quickly without thorough monitoring can lead to legitimate emails being blocklisted (or blacklisted).
Expert tips
Consult with your Email Service Provider to ensure they support DMARC for subdomains and get the exact DNS records needed.
Utilize DMARC reporting tools to gain visibility into your subdomain's email traffic and compliance rates.
Remember that while the sp tag is useful, an explicit DMARC record on a subdomain always overrides the organizational domain's policy.
Expert view
Expert from Email Geeks says you should probably reach out to your ESP representative to get the updated DNS entries needed for subdomains.
April 7, 2022 - Email Geeks
Expert view
Expert from Email Geeks says for DMARC alone, you don't need a separate subdomain policy unless you want it to be different from the organizational one.
April 7, 2022 - Email Geeks
Final thoughts
Setting up DMARC records for subdomains is a critical step in building a robust email authentication framework. Whether you opt for policy inheritance with the sp= tag or implement explicit DMARC records for each subdomain, the goal remains the same: to prevent unauthorized use of your domain and maintain a strong sending reputation. The complexity of modern email ecosystems, with various services sending on behalf of your domain, makes this level of control indispensable.
Remember that DMARC works in conjunction with SPF and DKIM. Ensuring alignment and proper configuration of all three protocols across your main domain and all subdomains is the most effective way to protect your email program from spoofing, phishing, and the detrimental impact of blocklists (or blacklists).
By following these guidelines and consistently monitoring your DMARC reports, you can significantly enhance your email security posture and improve deliverability for all your communications.
