DMARC at the subdomain level: When and why?

The intent behind DMARC (Domain-based Message Authentication, Reporting and Conformance) is to give a domain owner insight into who is sending mail using their domain and allow that domain owner to define a policy to tell ISPs what to do with mail that purports to be from them but doesn’t pass authentication checks (usually meaning that said mail is fraudulent). There’s a strong implication here that this is a domain level setting, it’s something that you would do at the highest possible level for your domain. Meaning here, I’d set a DMARC policy for spamresource.com, not for subdomains like newsletter.spamresource.com or email.spamresource.com. And generally speaking, that’s what you should do. It’s what I (usually) do.

But what if you want to get granular and do this differently with one or more (or all) subdomains of your domain name? Here are some options.

1. Do nothing (at the subdomain level). Maybe you’ll set a policy at the domain level instead. By default, that domain level policy trickles down to your subdomains. Meaning, if I configure a p=reject DMARC policy for spamresource.com, if somebody tries to send mail as email.spamresource.com, whether or not that succeeds or fails is going to be based on that domain level (spamresource.com) DMARC policy.
2. Use the sp= flag in your DMARC record to set a policy for all subdomains at once. I talked about that a couple years ago here – or really, I talked about how you probably do not need to do this. But in a nutshell, the p= flag sets DMARC policy for your domain, and the sp= flag sets DMARC policy for your subdomains. So you could choose to have p=reject for your topmost level domain and sp=quarantine as the setting to cover all of your subdomains. Keeping in mind, as I note above and in my prior guidance, that if you want, you can just omit the “sp=” variable from your DMARC record, and then by default, the domain level policy will apply to subdomains.
3. Set a DMARC policy explicitly for a specific subdomain by publishing a DMARC record for that subdomain directly. Like I’ve done here for squirtle.spamresource.com.

That third option is one that I’ve helped bunches of clients implement over the years and I’m thinking it’s one that most people aren’t familiar with (unless you’ve heard me yammering on about it specifically). It’s a good way to go for a unique a specific use case: If you don’t yet have a DMARC policy for the overall domain -- and if you’re not ready to implement one -- but a subdomain is being used ONLY by a specific email service provider, CRM tool or marketing cloud platform. You can get a useful, helpful level of security, by making it less useful for bad guys to spoof your email marketing subdomain, before you get to dealing with DMARC policy at the upper level domain.

If your organization or company is big or the org chart is convoluted, maybe you’ll have free rein over DNS settings for the subdomain, but not for the full domain. That’s a reason you might want to configure things this way. Lock down what you have access to, even if you don’t control the entirety of the universe for that domain name.

In a perfect world? Sure, implement DMARC policy for the whole domain. But I’ve run into so many clients where doing this company-wide or domain-wide can end up slowing them down (or preventing them from proceeding with DMARC at all) that I do strongly suggest starting with implementing DMARC for your marketing subdomain first, to give yourself a start, a quick win.

There’s an open question of which DMARC policy applies if you have a conflicting sp= policy from the upper level DMARC record versus the subdomain DMARC record. I’d assume that the explicitly-specified subdomain DMARC policy is the one that applies. And keep in mind that the use case here is best suited to folks who don’t already have an upper level DMARC policy published today.

So if you don’t already publish a DMARC policy for your whole domain, and if you’re in a situation where perhaps your ESP/CRM/email sending platform is suggesting that you implement DMARC just for the subdomain used on their platform: go for it. It’s a good next step as far as email security, anti-spoofing, and (indirectly) boosting your chances of deliverability success. Don’t stop there, if at all possible … but it’s not a bad place to start.