Using different DMARC records for subdomains

Each domain name may have only one DMARC record. When you connect multiple email services to a domain name, they will ask you to set different DMARC records. You can merge DMARC records, but that is not always practical.

Another solution is subdomains. Each email sender uses their own subdomain and has their own DMARC policy. This eliminates the problem of merging incompatible DMARC policies, but there are some drawbacks to this approach.

Here’s an example showing the DMARC records for a business’ root domain and separate DMARC policy for promotional and support subdomains:

_dmarc.example.org.             3600  TXT  "v=DMARC1; p=reject; aspf=s; rua=mailto:rua@example.org"
_dmarc.promotions.example.org.  3600  TXT  "v=DMARC1; p=reject; rua=mailto:promo_rua@example.org"
_dmarc.support.example.org.     3600  TXT  "v=DMARC1; p=reject; ri=604800; rua=mailto:support_rua@example.org"

These DMARC records all specify rejection for email failing DMARC checks, but there are some differences:

• Each subdomain has a different email address for aggregate DMARC reports
• The SPF domain alignment policy is strict for the domain itself but relaxed for the subdomains
• The support subdomain gets weekly aggregate reports instead of daily

DNS tree walking in DMARC

With three different DMARC records, how do mail servers determine which one to use?

The answer is DNS tree walking using the domain portion of RFC5322.From field in each email message.

What are RFC5322.From and RFC5321.MailFrom?

Every email contains an RFC5322.From field and an RFC5321.MailFrom field. They serve a different purpose:

• Mail clients display the email in the RFC5322.From field as the sender of an email.
• Mail servers send bounce emails to the email address in the RFC5321.MailFrom field when an email can’t be delivered.

Formal specification for DNS tree walking in DMARC is ongoing in the Internet draft “draft-ietf-dmarc-dmarcbis“.

This process involves walking up the DNS tree from the domain in the RFC5322.From field to search for a DMARC record. Using our example above, a receiving mail server would perform these DNS lookups if a message’s RFC5322.From field is sender@a.b.support.example.org:

• _dmarc.a.b.support.example.org –> No DMARC record found.
• _dmarc.b.support.example.org –> No DMARC record found.
• _dmarc.support.example.org –> DMARC record found!

DNS tree walking locates the DMARC record at the “closest” domain name at or above the RFC5322.From field. The algorithm also has a shortcut to prevent more than 5 DNS lookups. This shortcut prevents DMARC abuse by malicious parties.

Recipients will see the subdomain in emails

A drawback of using DMARC records for subdomains is that the address in the From field will appear to recipients of email as the subdomain and not the root domain for the business.

Instead of coming from example.org, a tech support email would come from support.example.org. It would be nice if all email from subdomains appeared to come from example.org.

Perhaps relaxed SPF domain alignment mode would allow this? Unfortunately, no. Strict SPF domain alignment mode requires that the two From fields match exactly. Relaxed SPF domain alignment mode allows them to be different, so long as they are related. But the relationship is “child only”. The RFC5321.MailFrom must be equal to or longer than the RFC5322.From domain.

This means that if RFC5322.From is alice@support.example.org then the RFC5321.MailFrom must be support.example.org in strict SPF domain alignment mode. Or some child domain of support.example.org in relaxed SPF domain alignment mode.

Security holes and subdomains

Another drawback is that subdomain administrators can inadvertently torpedo DMARC protection for the domain. Imagine that the domain has “p=reject” in its DMARC policy so that any email that fails DMARC checks is rejected. This is a good measure to combat spam.

Later, a subdomain DMARC record is created for promotional email. But the administrator for the subdomain doesn’t understand DMARC very well. They decide to set “p=none” so that no promotional email is ever rejected by DMARC:

_dmarc.example.org.             3600  TXT  "v=DMARC1; p=reject; rua=mailto:rua@example.org"
_dmarc.promotions.example.org.  3600  TXT  "v=DMARC1; p=none; rua=mailto:rua@example.org"

This pattern of DMARC records could allow phishing and spam attacks to be spoofed from promotions.example.org. Attackers could use this security hole to target customers of the business. This poor decision could harm the reputation of the company.

To prevent this sort of problem, administrators should review and approve all DMARC record changes anywhere in the domain to ensure that security standards are met.

Finding the DMARC record for a domain

DMARC records are stored as TXT records, so a standard TXT lookup will retrieve DMARC records. DMARC record names always begin with the label “_dmarc”. The dig or nslookup command line tools can be used. To find the DMARC record for Google, use this command:

dig TXT _dmarc.google.com

On operating systems that support nslookup, you can use the following:

nslookup -type=TXT _dmarc.google.com