DMARC uses the Domain Name System (DNS) to store records indicating how email receivers should evaluate incoming messages for authenticity. But one of the less well-understood aspects of DMARC is how receivers apply DMARC when subdomains are involved. While it may seem simple at first, the behavior can get complicated. When subdomains are involved there are a couple of important issues to understand. We’ll cover the first issue — how the DMARC policy records are queried — in this post. In other words, which DNS TXT records do receivers check?
Here are the basic rules:
- Receivers check for DMARC records based on the domain found in the RFC5322 From address, more colloquially known as just the ‘From’ address.
- Receivers will make either one or two DNS requests to find a DMARC record for a message, never more.
- If the From address on the message includes a subdomain, then the DMARC policy defined on a parent domain of that subdomain only applies if the parent domain is the ‘organizational domain’ (see below) and if no DMARC policy is defined for the subdomain. DMARC policies defined for any other domains in the tree are ignored.
Let’s work through an example. We’ll consider three messages, each with a From address on example.com or one of its subdomains.
The first set of DMARC records that will be checked is shown in the third column:
|First DMARC Record Domain
If a DMARC record is found at the first DMARC record domain, this lookup process stops. No further queries are performed for DMARC records, and the DMARC record retrieved from DNS for that domain is used for DMARC processing.
But if no DMARC record is found, the receiver may check another domain for the presence of the DMARC record. To determine this second location, DMARC introduces the notion of ‘organizational domain’. While the definition is a little complex, the process for determining the organizational domain is basically as follows:
- Take the domain from the ‘From’ address.
- Check the public suffix list for the largest suffix contained in the domain. For the .com, .edu, and many other popular TLDs, the suffix is just the TLD itself.
- Keep one label past the public suffix and discard the rest.
|service.co.uk (co.uk is the public suffix)
Let’s revisit our example above and see whether the receiver can make a second DNS request in each case and, if so, what domain is checked:
|Second DMARC Record Domain
In the first case, no additional DNS lookup is made for the DMARC record, as the organizational domain is the same as the From domain. So there’s no need to make the same check again.
In the second case, a second lookup is made (assuming no record was found on the first lookup). If a DMARC record is defined on _dmarc.example.com, that DMARC record will apply to this message.
The final case is probably the most confusing. As in the second case, a second lookup will be made and it will be made against the _dmarc.example.com domain. The important thing to note is that even though abc.xyz.example.com is a subdomain of xyz.example.com, there is no DMARC record lookup against _dmarc.xyz.example.com. So even if there’s a DMARC record defined on _dmarc.xyz.example.com, it won’t apply to this message.
Hopefully you now have a better idea of how DMARC record lookups work. Defining DMARC records on subdomains is definitely an advanced topic and, in most cases, is probably not necessary.
We cover the other issue that impacts DMARC use with subdomains — the use of the ‘sp’ tag — in a blog post on “How DMARC works with subdomains and the sp tag.”