DMARC is a protocol that makes it very, very simple to shoot yourself in the foot. Setup is tricky and if you don’t get it exactly right you risk creating deliverability problems. The vast majority of companies SHOULD NOT publish a DMARC policy with p=reject or p=quarantine for their existing domains.
DMARC policy statements are, essentially, a way for a company to assert the following things are true:
- They know exactly where every legitimate piece of email they send comes from.
- They have authenticated every legitimate piece of email in a very specific set of ways.
- They are sure that any email not authenticated in those very specific ways is not legitimate and should be thrown away.
Typically, these things are hard to get right. And even when you get #1 and #2 perfectly correct there will be other mail servers handling the mail that can break authentication in ways that cause DMARC to fail. Thus, all DMARC policy statements other than p=none will result in delivery failures for legitimate email.
There are some cases where, with a little time and energy, it’s possible to get everything right. The obvious one is when you’re spinning up a brand new domain used for just one type of email. With a little bit of time, understanding, and care it’s possible to correctly authenticate every piece of email sent regarding that domain. Sure, there will still be a few delivery failures due to forwarding or other modifications after the mail leaves your server, but overall all mail sent is correctly authenticated.
In most cases, though, companies don’t start with a brand new domain. They try and shoehorn DMARC authentication into an existing company. This is where things get really tricky.
For instance, here at WttW we have a company where everyone is an expert in the field of email. We know where all our mail comes from, right? It all comes out the SMTP server we maintain. Well, except for the stuff that goes out of Mailchimp. Oh, and the mail that goes out of Hubspot. Don’t forget the Google calendar invites. Wait, we send some reminders from Asana. And the system update emails that come out of our various monitoring boxes. What about the various email discussion lists we participate on. And the invoices we send out through various services. Also the receipts from credit card processing.
Are all those emails authenticated? Yup. They absolutely are. Are all of the emails authenticated in the special ways that would allow us to publish a DMARC policy statement? No. Can they be? Absolutely not.
DMARC breaks the way many people and companies use email. Some of this breakage can be worked around, although in ways that make some things harder. Some simply cannot be worked around and publishing any policy other than p=none means that some mail will be put in the spam folder or rejected.
This doesn’t mean no one should use DMARC. There are some use cases where it makes a lot of sense. In those cases the cost of fraudulent emails is high enough that losing a few legitimate emails is an acceptable cost. DMARC policy statements aren’t for every domain. And if you’re starting a mail program on a new domain from scratch, you can make engineering and provider choices that make DMARC authentication possible.
To me the real value of DMARC is actually the reporting piece. This allows companies to see what mainstreams they actually have and how they’re being authenticated. There is also some value for heavily phished domains. But, as I’ve said in the past, most phishing is using cousin domains and DMARC doesn’t address cousin domain phishing at all.
All of this is a long way of saying that DMARC policy statements of p=reject and p=quarantine will hurt your deliverability and result in lost email. For a small fraction of companies the benefit outweighs the problems of lost mail. For most companies, however, p=none is sufficient to get the benefits with few of the downsides.
Still not convinced and want to go forward with DMARC? My best bit of advice is don’t do it yourself. Use one of the DMARC consulting companies so they can help you through the process.