Differentiating Subdomains and Organizational Domains

Subdomains Can Inherit DMARC Policy

One of the great things about DMARC is that subdomains can inherit the DMARC policies of organizational domains. If a subdomain does not have a DMARC record designating a policy, then that subdomain will inherit and have the same DMARC policy as its organizational domain.

DMARC Policy May Be Different Between Subdomains and Organizational Domains

Use of the DMARC sp= tag is beneficial since it allows you to configure it once at the organizational domain and it will manage the subdomains associated with it differently, according to how you configure the sp= tag for the different policies you would like to enforce on the subdomains. This is a good strategy if your organization wants to maintain separate DMARC policy for the top-level domains and all subdomains.

Using Subdomains to Manage Third-Party Senders

A best practice is to put 3rd party senders on subdomains. This is beneficial for DNS include mechanism and SPF record limitation reasons, as well as provide more granular control of specific subdomains and their associated SPF records for DMARC authentication and alignment. 

If you do not want the end-user to have visibility to the subdomain, you may choose to keep the 5321.MailFrom at the subdomain to pass SPF, and have the 5322.From to use the organizational domain; thus DMARC will pass in relaxed mode. Not all 3rd party senders provide separate customized 5321 and 5322 addresses, but if they can support it, it is a good compromise for organizations that may have a policy that dictates that all email comes from their organizational domain. If you choose to change the 5322 to use the subdomain, you can move the subdomain to reject or keep at none, or quarantine - independent of the organizational domain.

Usage Examples - Subdomain SP= tag 

For no valid subdomain traffic, applying reject policy - example.com has:

v=DMARC1;p=reject;sp=reject;rua=mailto:example@rua.agari.com;ruf=mailto:example@ruf.agari.com;

When sp= defaults to the p= if the former is not present:

v=DMARC1;p=reject;rua=mailto:example@rua.agari.com;ruf=mailto:example@ruf.agari.com;

For individual subdomains at reject and organization domain at monitor - example.com has:

v=DMARC1;p=none; sp=none; rua=mailto:example@rua.agari.com;ruf=mailto:example@ruf.agari.com;

Whereas, subdomain.example.com may have

v=DMARC1;p=reject;rua=mailto:example@rua.agari.com;ruf=mailto:example@ruf.agari.com;

For organizational domain at reject and subdomains at the monitor (unless they have specifically overriding p=reject records at their subdomain level ) example.com has:

v=DMARC1;p=reject; sp=none;rua=mailto:example@rua.agari.com;ruf=mailto:example@ruf.agari.com;

Whereas, subdomain.example.com may have this to override:
v=DMARC1;p=reject;rua=mailto:example@rua.agari.com;ruf=mailto:example@ruf.agari.com;

General Information on Subdomains 

The SP tag is useful when all sub-domains are to enforce the same rule. It can be configured once on the organizational domain. If you would like a subdomain to have a different DMARC policy from the organizational domain, then you will need to configure the sp= tag. This will allow you to provide the DMARC policy you would like to enforce for the subdomains of the domain.

Alternately, if you have different subdomains with different policies, then you will configure DMARC records individually for each subdomain.

If there is no sp= tag the subdomain policy (sp) will be the same as what is enforced on the domain policy (p) "v=DMARC1; p=reject;"

If you would like subdomains to inherit the DMARC record of the organizational domain, but not the reject policy then you would need to change the record to "v=DMARC1; p=reject; sp=none;"

Further Resources

For further information on using a subdomain policy with DMARC, please review our article on Using a Subdomain Policy with DMARC. 

For further DMARC information, please review more of our articles and/or visit the DMARC Overview page from the organization behind DMARC.