All Collections
Learn about DMARC
How does DMARC protect subdomains?
How does DMARC protect subdomains?

DMARC protection and record syntax for subdomains

Ivan Kovachev avatar
Written by Ivan Kovachev
Updated over a week ago

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?