When it comes to phishing, many brands make the mistake of relying on their customers or employees to identify and report attacks.
But this strategy is flawed. 97 percent of users around the globe cannot correctly identify a sophisticated phishing message.
Technology that blocks malicious messages before they reach the inbox must be the first line of defense against email fraud. And the DMARC (Domain-based Message Authentication Reporting and Conformance) standard does just that.
Building your DMARC record is pretty straightforward. But there are many common misconceptions about the DMARC implementation process which can throw a wrench in your efforts to identify and mitigate phishing attacks.
Since Return Path’s Managed Service team hears these DMARC misconceptions on a daily basis from the field, we thought it might be helpful to list—and debunk—the top ten here
1. DMARC reporting mechanisms contain sufficient data to deploy a DMARC “reject” policy successfully.
You actually need additional data to give the RUA and RUF context, or you end up relying on guesswork, which can be nerve-wracking.
2. It’s a good idea to list all the possible header fields in your DKIM signature because it’s “more secure.”
Your goal with DKIM is to cryptographically validate that only you could have sent the message in question. Therefore, pick only a few fields to put in your “h:array,” none of which will be changed by forwarding (which would cause your signature to break).
3. You should add “include” statements to your SPF record instead of entering either individual IPs, or a CIDR (Classless Inter-Domain Routing) range.
Your SPF record needs to be a lean, mean speed machine—ideally, a clean, flat list of IPs. Keep include statements to an absolute minimum. Doing so adds speed and removes a potential point of failure
4. Add an 11th include statement to your SPF record.
The SPF protocol only allows for 10 include statements. Adding an 11th include statement breaks the record.
5. Emailing your DKIM private key to someone isn’t a big deal.
The second that your private key is anywhere other than the MTA which uses it, it’s no longer a private key and has to be replaced.
6. You should send all email from the organizational/top-level domain.
There are many reasons to note here why sending email from your top-level domain is a bad idea. Some are based on security and vendor management—your holiday booking system is happiest sending from [email protected] Others on sound deliverability grounds—you never want to mix a marketing and transactional email, for example. See this resource from Google for more detail.
7. A DMARC record in the organizational/top-level domain is all you need.
Implementing DMARC on your top-level domain is a good start, but it’s not enough to give you the control and the reporting fidelity that you need. All domains owned by your company (both sending and non-sending) should be protected with a DMARC policy.
8. Because you send the majority of your email from a certain subdomain, the bad guys will do that as well.
This is a common assumption, and it’s false—you need to lock down the entire domain (the main organizational domain and the subdomains). The highest value target is the organizational domain, not the subdomain you send the most volume from.
9. Previous infrastructure decisions were made rationally.
Don’t drive yourself mad trying to replicate the thought process of those who built your email infrastructure. Instead, use the new DMARC deployment as an opportunity to re-design and optimize your (and your third party) infrastructure and architecture.
10. Vendors in 2016 can all sign DKIM.
“Should” isn’t the same as “can.” The vendor landscape is highly varied. You need an expert who has detailed knowledge of how to overcome the various challenges you will face getting all of your infrastructure to authenticate correctly with DKIM, in particular when it comes to third party vendors.
Want to run your DMARC implementation process by an email expert at Return Path? Please reach out to us. We’d love to answer any questions you may have.