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.

Did this answer your question?