Going deep: DMARC at the sub-sub-domain level?

Here's a new and unique question that I was just asked: What about DMARC at the sub-subdomain level, multiple levels deep?

If I have a DMARC record for my subdomain e.spamresource.com, and then I set up a subdomain one level deeper, maybe transactional.e.spamresource.com, and THAT subdomain doesn't have a DMARC record, won't it inherit the DMARC record from e.spamresource.com? Doesn't DMARC always "trickle down" at every level? Nope! Read on to understand why.

Most DMARC checkers aren't going to find (and shouldn't find) a DMARC policy for transactional.e.spamresource.com by checking one level up in DNS, by looking for the DMARC policy for e.spamresource.com. (You'll probably find one or more DMARC checkers that WILL find a DMARC policy that way -- but they're doing it wrong; either taking shortcuts with the DNS tree logic for how DMARC policy should apply, or they're doing it wrong.)

Back to the actual question -- where should spam filterers and mailbox providers be looking for the DMARC policy to apply to a sub-sub-domain, like transactional.e.spamresource.com?

Let's get nerdy and turn to the specification for guidance. That would be RFC 7489, section 6.6.3. It's pretty clear, I think, but allow me to translate it into my own words:

1. Receivers have to check for a DMARC record for the RFC5322.From domain. The visible from domain. The exact domain or subdomain used in the visible from address.
2. If you find garbage, ignore it and move on. If it's not clearly a DMARC record, skip it.
3. If nothing was found, check at the organizational level of the domain instead. This means, in my case, that we should check for a DMARC record for "spamresource.com" -- at the topmost level for this domain.
4. If you find garbage at this level, ignore it and move on. If it's not clearly a DMARC record, skip it.
5. If you got this far and found no DMARC record at the organizational level of the domain, don't apply DMARC policy to this message as there is no DMARC policy for this domain.

In other words: there's no "walk up a single subdomain level" step in the hierarchy of DMARC domain/subdomain checks. You can implement specific DMARC records at the subdomain (or even sub-subdomain) level, you can implement specific DMARC records at the organizational domain level, and you can even do both. But the only thing that "trickles down" is going to come from the topmost level. Subdomains don't trickle.

What of the sp= (subdomain policy) tag? Here, Valimail explains how DMARC is meant to cover subdomains via the sp= tag. Set the sp= tag at the organizational domain level to apply a subdomain policy across the board. It'll apply to any subdomain that doesn't have its own DMARC record. Any subdomain that DOES have a DMARC record, THAT published subdomain-level policy applies to that subdomain.

And section 6.3 of RFC 7489 warns us that "sp" is useless at the subdomain level: "Note that 'sp' will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the [way that the] DMARC policy discovery mechanism [works.]" If I were to add an sp= policy tag to the DMARC record for my e.spamresource.com subdomain, there's no legitimate scenario where a DMARC check for transactional.e.spamresource.com would find that sp= policy and apply it anywhere. 

TL;DR? DMARC policy and settings trickle down only from the topmost level (organizational domain level in DNS); the spec says it is perfectly fine to publish a DMARC record for a subdomain; but that record would not itself result in its policy "trickling down" to any subdomains below it in the domain hierarchy.

I don't really want to turn this into a discussion around what DMARC policy you should be setting, but I can see a scenario where you'd be able to specify varying DMARC policies at different levels, via all of these legitimate mechanisms, all at once:

1. Publish a specific p= DMARC policy at the top (organizational domain) level.
2. Publish a different DMARC policy for subdomains via the sp= tag in that same top level DMARC record. Consider this your default DMARC policy for all subdomains.
3. Publish a specific p= DMARC policy at a subdomain level, for any subdomains that needs a different policy than the default. As an example, perhaps you prefer a DMARC policy of "quarantine" for all subdomains, but you've got a now-dead subdomain that you consider retired. You might directly publish a DMARC record at the subdomain level, with a policy of reject. This policy would not apply to any other subdomain, and would not "trickle down" in any way.

Juggling subdomains (or sub-subdomains) for different types of email streams, different services, different providers, can be a logistical challenge. Lots of different settings to keep straight, but at least it's easy to map out where the DMARC policy is pulled from in the domain/subdomain hierarchy.