From time to time here at SparkPost, in conversations with both customers and other employees, I run across the same kinds of misconceptions about email authentication, specifically regarding DMARC. There is a lot that DMARC (and SPF, and DKIM) can do for you and your brand, but there are many things that it can’t do. This is not a post that’s intended to tell you how to set up any of these three protocols. We have other blogs posts that highlight how to implement SPF authentication, DKIM validation and DMARC. Instead, we want to make sure that everyone reading this understands the value authentication can bring, but also some of its limitations.
Authentication Affirms Your Identity…
When an email message passes authentication checks, the receiving domain can be reasonably sure of the identity of the domain(s) that claimed responsibility for the message through publishing an SPF and/or DMARC record, or DKIM signing the message. In this way, authentication is most like presenting a driver’s license, passport, or other picture ID to someone to affirm your personal identity.
…But It Doesn’t, By Itself, Earn You A Good Reputation
The act of passing authentication checks means that the receiving domain can reliably establish the identity of the party or parties responsible for the message. It follows then that the receiving domain can reliably treat that message in keeping with the reputation that those parties have previously established. In short, if authentication is the only good thing about your mailing practices, passing authentication will allow the receiving domain to more confidently place your mail in the spam folder (or worse) if your other practices warrant such placement. I like to stress this point in conversations by telling people that “even criminals carry driver’s licenses”.
DMARC Establishes and Affirms Trust in Email…
Similar to the concept of authentication providing a means to reliably establish the identity of the parties responsible for the message, a message that passes DMARC checks can be trusted to be from the domain that appears in the message’s “From” header, which is the domain that the recipient is most likely to see when reading the message. Trust in email is key to engagement, as messages that can be trusted to be from the claimed sender are more likely to be opened and clicked on. Moreover, with DMARC looking to be required for the developing BIMI standard, this “force multiplication” of trust will be even more important to senders going forward.
…But It Doesn’t Totally Eliminate Phishing and Fraud…
DMARC is what I like to call a “positive assertion” protocol, in that it makes a statement about a specific domain’s authentication practices, but says nothing about any other domain’s practices. A published DMARC policy for domain X means that domain X authenticates its mail and that it requests a specific kind of treatment for unauthenticated mail using domain X in the From: header, and that’s it. The policy doesn’t cover the independent use of domain X in the DKIM signature or return-path domain (which is used in SPF checking) and more importantly, it doesn’t cover domains that might look like domain X but aren’t quite the same.
Consider the following two messages, both with this subject:
Subject: Critical Account Update Information
One has this From: header:
From: “Your Bank” <email@example.com>
And the other has this:
From: “Your Bank” <firstname.lastname@example.org>
A DMARC policy for the domain ‘yourbank.com’ will only serve to validate the first message; it won’t do anything to influence the second. If Your Bank was forward-thinking enough to register such a “lookalike” domain, then it could certainly publish a policy that effectively says “this domain sends no mail”, but there are probably more lookalike domains than even the most diligent domain owner could register, and so DMARC alone can’t stop all of them. (BIMI might help mitigate some of the risk here, what with its display of brand logos for mail that passes DMARC checks, but we’re a long way from widespread adoption of BIMI.)
…Especially If The Receiving Domain Isn’t Checking DMARC
No matter how many DMARC policies a brand owner publishes for its domains, those policies are worthless unless the domain receiving mail claiming to be from one of those domains actually does DMARC validation. Validation is in widespread usage across the email ecosystem, but there are still many domains out there, both large and small, that aren’t doing DMARC validation, and so mailbox holders at those domains are at a higher risk of phishing and fraud than are those at domains that check and enforce DMARC policies.
Email authentication has its place as a tool to reliably establish identity and trust for email, but at the same time shown its limitations in affirming reputation and stopping phishing and fraud. SparkPost fully supports the idea of email authentication as being a best practice and being good for the overall email ecosystem, but we want to make sure our customers fully understand that it’s only one part of an overall strategy for establishing reputation and fighting phishing and fraud.