DMARC’s Subdomain Policy (sp) Tag
We often get questions about how DMARC policies apply to subdomains and how to establish a subdomain policy. Here’s some information to provide clarity and answer those questions.
Because subdomains contend with the same abuse potential as parent domains, aka top-level or root domains, the astute authors of the DMARC control wrote specific conditions for subdomain policies. It goes like this: subdomains inherit the parent domain’s DMARC policy unless you indicate a subdomain policy using the sp= tag in the parent DMARC record or publish a p= tag on a subdomain.
Keeping in mind that cybercriminals leverage unprotected subdomains for phishing exploits, it’s important to have a DMARC deployment plan for every subdomain you create, whether the parent domain DMARC policy is inherited, an sp= tag is published to rule the subdomains, or a p= tag is indicated for the subdomain.
The DMARC policy definitions and actions apply to subdomain policies just as they do for parent domain policies. Here’s a review of how those work and best practices to follow when it’s time to start progressing your DMARC policies.
Publishing a DMARC Policy Inherited by Subdomains
If you want to publish the same DMARC policy for the parent domain and its subdomains, a p= tag on the parent domain does the job. The example below illustrates a DMARC record published for example.com with an enforcement policy of p=reject; with no sp= tag, the p=reject policy covers the parent domain and its subdomains that have no explicit DMARC policy tag:
v=DMARC1; p=reject; rua=mailto:example@example.com
Publishing Different Policies for Parent Domain and Subdomains
To publish a subdomain policy on the parent domain, create a DMARC record that includes an sp= tag to specify a DMARC policy for subdomains of the relative parent domain. Here’s a DMARC record published for example.com that covers the parent domain at p=quarantine and its subdomains at p=reject:
v=DMARC1; p=quarantine; sp=reject; rua=mailto:example@example.com
Publishing an Explicit Subdomain Policy
To publish a subdomain policy for a single subdomain, create a DMARC record for the subdomain that includes a p= tag to specify a DMARC policy. This policy supersedes the p= and sp= tags that may be published on the parent domain. Here’s an example for the subdomain welcome.example.com at p=reject:
v=DMARC1; p=reject; rua=mailto:example@example.com
Managing Subdomains with DMARC
From security, operational and deliverability perspectives, dmarcian advocates for the segmentation strategy for SPF management. We recommend that different email streams (types of traffic) be separated when possible. The idea is to separate streams per type, such as bulk marketing, transactional, billing, specific third-party vendors, operational entities, and so on.
To achieve this, it is also a best practice to separate email traffic into subdomains dedicated to those streams. Doing so increases visibility into each stream, isolating the use of a particular system or vendor. When SPF authentication is necessary, it also brings added security and operational simplicity by offloading the burden of a single-domain approach and avoiding SPF bloating. It’s important to note that each segment should grow its own reputation, which necessitates consistent traffic volume. Variation or lapse in usage on a subdomain can impact reputation and deliverability.
You should carefully manage subdomains and ensure that all legitimate email traffic is covered by explicit DMARC policies. Even if you don’t use subdomains, there’s wisdom in publishing an sp=reject policy immediately while only collecting data on your parent domain using p=none. This approach allows you to work through DMARC deployment and policy advancement at your own pace while disallowing the use of subdomains by criminals in phishing exploits.
The sending domain is one of the most important aspects of email sending configuration and can greatly impact both message delivery rates and the perception of the message by the recipient. The most important point to take away from this document is that when choosing a sending domain, a subdomain of the sender’s organizational domain should be selected in almost all cases.
M3AAWG’s Sending Domains Best Common Practices
If you have any questions about how to manage your subdomain DMARC policies, let us know.
We’re Here to Help
With a team of email security experts and a mission of making email and the internet more trustworthy through domain security, dmarcian is here to help assess an organization’s domain catalog and implement and manage DMARC for the long haul.
Want to continue the conversation? Head over to the dmarcian Forum.
