Phishing and email spam are the biggest opportunities for hackers to enter the network. If a single user clicks on some malicious email attachment, it can compromise an entire enterprise with ransomware, cryptojacking scripts, data leakages, or privilege escalation exploits.
Email security protocols have been invented to reduce these opportunities. Like much in the IT world, the multiple solutions don’t all necessarily overlap. Actually, they are quite complementary to each other, and chances are good that the average business will need all three of these solutions:
- Sender Policy Framework (SPF), which hardens your DNS servers and restricts who can send emails from your domain.
- DomainKeys Identified Mail (DKIM), which ensures that the contents of your emails remains trusted and hasn’t been tampered with or compromised.
- Domain-based Message Authentication, Reporting and Conformance (DMARC), which ties the first two protocols together with a consistent set of policies.
The reason for the three different approaches is partly because each solves a somewhat different piece of the email puzzle to prevent phishing and spam. This is accomplished via a combination of standard authentication and encryption tools, such as public and private key signing, and adding special DNS records to authenticate email coming from your domains.
It also has to do with the evolution of the internet email protocols themselves. In the early days of the internet, email was mostly used among university researchers, where like the Cheers TV bar, everyone knew your name and trusted each other. Sadly, those days are long gone.
The message headers (such as the To: and From: and Bcc: addresses) were deliberately separated from the actual content of the message itself. This was a feature (and if you think about how Bcc: works, you realize why it is important), but that separation has brought new worlds of pain for IT administrators of the modern era.
Use SPF, DKIM and DMARC together
If your email infrastructure implements all three protocols properly, you can ensure that messages can’t be easily forged and that you can block them from ever darkening your users’ inboxes. That’s the idea anyway, and as you’ll see, a big if.
Over the past year, the trio of protocols has received more attention because of several factors. First, spam and spear phishing continue to be issues, and as more networks are compromised because of them, IT managers are looking for better security solutions. Second, the feds have become involved. The Department of Homeland Security issued an order last year requiring all agencies to come up with action plans to implement these protocols. Agencies in the UK and Australia have followed suit.
Third, email providers such as Google’s Gmail, Yahoo, and Fastmail have implemented the trio across their hosted email solutions, because they want to keep their customers protected. Finally, some decent protective products and SaaS tools can be used to implement these protocols. Vendors such as Valimail, Agari, Barracuda, and others are gaining traction. (Note: I tested Valimail on my own email infrastructure and used the experience in writing this report.)
So that is all good news. Let’s look at the complicating factors.
Confusing information on these protocols
Late last year, a security researcher posted this article on how he could break DKIM using a specific set of customized email messages that made use of multiple Subject: headers. While he had a few points about the practice and implementation of DKIM, Valimail (which sells a managed DKIM solution) called him out, saying he didn’t quite understand what he was doing, and that he was talking about some insignificant edge cases.
In most cases, email clients would have failed to authenticate these multiple-subject messages. To get better insight, take a look at this good (but lengthy) explanation of how Fastmail deployed these protocols. You can see after reviewing this document how hard it is to keep the roles of the three protocols straight.
Adding to the confusion are conflicting usage surveys. While a survey by Google showed that 85 percent of received emails in its Gmail infrastructure were using some protection, that isn’t true for the average enterprise email user. A recent report from consultancy 250ok analyzed 3,000 of the top ecommerce retailers in the US and Europe found that nearly a fifth of them hadn’t yet implemented any additional email security across their sites. Only 11 percent of the respondents had both DMARC and SPF properly setup. This agrees with a recent survey from Agari, which shows that only 8 percent of the F500 use DMARC properly, and only 2 percent of total domains have any protection whatsoever. This brings us to my next point:
Setting up DMARC, DKIM and SPF is not easy and subject to operator error
For example, for SPF and DMARC to work, you have to set it up for every domain you own. If your company operates a lot of domains or subdomains, the setup can get tedious very quickly. You have to make sure that every subdomain is protected with the right DNS entries, too.
If you are using Google for your email, they have instructions about DKIM and how to generate your domain key. If you are using cPanel to manage your domain, they have suggestions on how to configure the various DNS records. Once you think you are done, you can use and online tool to validate that the appropriate DKIM keys are happening in your email headers.
While there are tools to help, getting everything configured will require very specialized skills. Even your corporate DNS guru might not be familiar with the commands required by each protocol, not because of lack of knowledge but because they aren’t widely used and their syntax can be maddening to get exactly right. One thing that can help: Setting up the protocols in a specific order.
This blog post from Easysol suggests starting with SPF, then moving to DKIM, and then finally tackling DMARC. SPF is easier to deploy, so that is why you should do it first. When you get around to DMARC, start by using its monitoring-only mode before you begin blocking any emails to ensure you have everything set properly. When I set them up on my own domains, that is exactly the same path that I took.
Track down all your apps that consume email
When I first began implementing these protocols, I thought I had a relatively simple situation. After all, it is just me, myself, and I running my email infrastructure. Even with a company size of one, I had some issues. For example, I run a few subdomains and was sloppy about how I implemented my email being sent from a mailing list. I use WordPress as my blogging server, which sends email notifications of various kinds and from different plug-ins. Some of the comments that were posted to my blog send me email notifications that weren’t being initially authenticated and required some adjustment.
This is why it took me several months to work out all these details. If you are running a lot of apps across your enterprise, you probably need to search out those that are connecting to your email infrastructure and set them up to use the right authentication methods. Some might not support DMARC or one of the other protocols, and then you have to figure out a way around it or deal with the fact that some of your emails may not be up to snuff.
As you can see, the DMARC/DKIM/SPF journey isn’t a simple one, with lots of side roads and diversions. Make sure you get top management buy-in and don’t underestimate the amount of time to complete the project.