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 do not 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 realise 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 cannot be easily forged and that you can block them from ever darkening your users’ inboxes. That is the idea anyway, and as you will 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 US 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 us 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 customised 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% 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 analysed 3,000 of the top ecommerce retailers in the US and Europe found that nearly a fifth of them had not yet implemented any additional email security across their sites. Only 11% of the respondents had both DMARC and SPF properly setup. This agrees with a recent survey from Agari, which shows that only 8% of the F500 use DMARC properly, and only 2% of total domains have any protection whatsoever. This brings to the next point.
DMARC, DKIM and SPF set up is not easy
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 specialised 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 are not 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.
Track down all apps that consume email
When first implementing these protocols, it can look like a relatively simple situation. However, even with a company size of one, there can be some issues. For example, if running a few subdomains, and mailing lists from content management systems, such as WordPress, things can be complicated.
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 is not 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.
IDG News Service
Ltd
