How DMARC Works With Subdomains (DMARC sp Tag)?

Home How DMARC Works With Subdomains (DMARC sp Tag)?

How DMARC Works With Subdomains (DMARC sp Tag)?

20th Feb 2024 DMARC Subdomain sp

We will cover a lesser discussed DMARC topic in this article: how does DMARC work in subdomain scenarios?

Specifically, we will address these questions below:

how DMARC policy discovery works?
how DMARC policy inheritance works?
should one use the sp tag to protect subdomains?

Before diving into various DMARC subdomain scenarios, we need to introduce the concept of organizational domain.

What is an organizational domain in DMARC?

An organizational domain is the "root domain/top-level domain" of a domain name. That is, a domain name with all the subdomains removed. The following is a few domain names and their organizational domains:

Domain Name	Organizational Domain
example.com	example.com
sales.example.com	example.com
mail.sales.example.com	example.com
sales.example.co.us	example.co.us

The organizational domain is determined by breaking the subject domain name, then matching the parts with a public suffix list (PSL) containing top-level domains (TLDs), including country TLDs, e.g., ".co.us" in the U.S. and ".co.uk" in the U.K.

Here is a PSL maintained by Mozilla Foundation.

How DMARC policy discovery works

When an email message arrives at the receiving server, it needs to apply DMARC to the email message. In order to do this, the server tries to find the DMARC policy via a process known as DMARC policy discovery.

DMARC policy discovery goes through these steps to find the DMARC policy for an incoming email message:

Determine the RFC5322.From domain of the email message;
Query the DNS for a DMARC record on the RFC5322.From domain found in step 1; depending on the outcome:
- if only 1 DMARC record is found, the policy in the record is returned;
- if multiple DMARC records are found, policy discovery terminates and DMARC processing is not applied to this message;
- if no DMARC record is found, go to step 3;
Query the DNS for a DMARC record on the organizational domain of the RFC5322.From domain, if the 2 domains are different; depending on the outcome:
- if only 1 DMARC record is found, the policy in the record is returned;
- if no DMARC record is found or multiple DMARC records are found, policy discovery terminates and DMARC processing is not applied to this message;
If a retrieved policy doesn't contain a valid p tag:
- if a rua tag with at least one valid reporting URI is present, the receiving server applies p=none to the message;
- otherwise, policy discovery terminates and DMARC processing is not applied to this message;

Note that at most 2 DNS queries are issued in each DMARC policy discovery process. One for the RFC5322.From domain, and the other for the organizational domain (if different than the RFC5322.From domain).

If you have multiple levels of subdomains, no DNS query will be issued for the intermediate subdomains. This is necessary to reduce the workload on the DNS due to multiple DNS queries on subdomains.

For example, if the RFC5322.From domain is it.sales.example.com, only 1 DNS query will be issued for it.sales.example.com, and possibly 1 DNS query for example.com. No DNS query will be issued for sales.example.com, as it's an intermediate subdomain.

How DMARC policy inheritance works

The DMARC policy inheritance mechanism allows domain owners to set DMARC policies on subdomains in a flexible way.

The DMARC policy inheritance rules work like below.

Scenario: subdomain inherits organizational domain's p policy

If the organizational domain has a DMARC record with a policy (p tag) but no subdomain policy (sp tag), while the subdomain doesn't have a DMARC record, the subdomain inherits the organizational domain's p policy.

For example, if there is a DMARC record published on example.com, as shown below:

example.com     "v=DMARC1; p=reject;"

Now that example.com's policy is reject, any example.com's subdomain without a DMARC record will have a reject policy.

Scenario: subdomain inherits organizational domain's sp policy

If the organizational domain has a DMARC record with a policy (p tag) and a subdomain policy (sp tag), while the subdomain doesn't have a DMARC record, the subdomain inherits the organizational domain's subdomain policy.

For example, if there is a DMARC record published on example.com, as shown below:

example.com     "v=DMARC1; p=reject; sp=quarantine;"

Since example.com's sp policy is explicitly set to quarantine, any example.com's subdomain without a DMARC record will have a quarantine policy.

Scenario: subdomain overrides organizational domain's policy

If the organizational domain has a DMARC record with a policy (p tag) and a subdomain policy (sp tag), while the subdomain has its own policy (p tag), the subdomain overrides the organizational domain's subdomain policy with its own policy.

For example, if there is a DMARC record published on example.com, as shown below:

example.com     "v=DMARC1; p=reject; sp=reject;"

and a DMARC record published on sales.example.com:

sales.example.com     "v=DMARC1; p=quarantine;"

In this scenario, sales.example.com's own policy overrides example.com's policy. Therefore, p=quarantine is applied to sales.example.com.

Scenario: subdomain policy published on subdomain

When an sp tag is used in a DMARC record published on a subdomain, the sp tag will be ignored due to the effect of the DMARC policy discovery process.

For example, if you have a DMARC record on a subdomain:

sales.example.com     "v=DMARC1; p=reject; sp=quarantine;"

the sp tag has no effect on sales.example.com or any subdomains under sales.example.com such as it.sales.example.com.

Best practices for DMARC with subdomains

After you reach p=reject on your organizational domain, you should also protect your subdomains with p=reject. This is because even if your subdomains' DMARC policy is p=none or p=quarantine, adversaries can still deliver emails on behalf of your subdomains.

This can be easily achieved by setting your organizational domain's policy to p=reject, and don't override it on any subdomains. This way, all the subdomains under your organizational domain will have p=reject, and no one without explicit authorization can deliver emails on behalf of your organization!

SPF works differently with subdomains in that it doesn't go up and check the root domain for a fallback record. Refer to How SPF Works With Subdomains
How DKIM Works With Subdomains