By default, the policy “p=” tag specified in your DMARC record applies to the domain that it is created under and any subdomains. This means that if your domain is in "p=reject", all subdomains of that domain will inherit the policy and will also be in "p=reject". Take a look at Scenario 1 below for further explanation.
Scenario 1. Subdomains inheriting the DMARC policy
Let's take the following DMARC record created under the domain protected.com
as an example:
protected.com DMARC record: "v=DMARC1; p=reject;"
The policy “p=reject” tag above means that protected.com
is in "p=reject" and any subdomains such as sub.protected.com
by default are also in "p=reject".
However, the DMARC record syntax allows domain administrators to specify one policy for their top-level domain and a different DMARC policy for their subdomains using an additional tag "sp=" which stands for subdomain policy. Take a look at Scenario 2 below.
Scenario 2. Top-level domain with a subdomain policy
Let's take the following DMARC record created under the domain protected.com
as an example :
protected.com DMARC record: "v=DMARC1; p=reject; sp=none"
The DMARC record above states that the domain protected.com
has a policy of "reject", while any subdomains such sub.protected.com
and sub2.protected.com
have a policy of "none".
You can see how a subdomain can have a different DMARC policy without even having a DMARC record itself. So, what happens if the subdomain has its own DMARC record? Take a look at Scenario 3 below for the answer.
Scenario 3. The subdomain having its own DMARC record
A subdomain only inherits the DMARC policy of the top-level domain if it does not have a DMARC record itself. This means that even if the top-level domain has "p=" or "sp=" tags they do not matter.
Let's take a look at the following examples:
protected.com DMARC record: "v=DMARC1; p=reject; sp=none"
sub.protected.com DMARC record: "v=DMARC1; p=reject;"
sub2.protected.com NO DMARC RECORD
You can see that the domain protected.com
has "none" subdomain policy specified, sub.protected.com
has its own DMARC record with a policy of "reject" and sub2.protected.com
does not have a DMARC record. In this scenario sub.protected.com
will not inherit the subdomain DMARC policy from the top-level domain because it has its own DMARC record, and therefore will stay in "reject", while sub2.protected.com
will inherit the subdomain policy because it does not have a DMARC record itself.
Why is the above important?
Well, it allows domain administrators to protect different domains / subdomains based on how far they are along the DMARC journey.
For example, if all your email sending services sending emails on behalf of your top-level domain are fully configured with SPF and DKIM, that means that you can protect your top-level domain with a DMARC policy of "reject" while keeping the subdomains in "none", and vice versa.
Also, if you have an email sending service that is non-dmarc compliant ie. does not support SPF or DKIM, you may decide to assign a subdomain to it and have that subdomain in a different DMARC policy, without preventing you from protecting your other domains. This allows you to split the traffic into different sub/domains and protect each one separately.