- It’s essential to understand the differences between the three modern email protection protocols.
- You must also learn how to deploy them effectively.
- Used correctly, they can protect your email servers and domain reputation from hackers.
We all know that phishing and email spam are the biggest opportunity for hackers to enter our networks. As we wrote about in this earlier post, this could result in our email servers being blacklisted. If a single user clicks on some malicious email attachment, it can compromise an entire enterprise with ransomware, cryptojacking, data leakages or privilege escalation exploits. Over the years a number of security protocols have been invented to try to reduce these opportunities. This is especially needed today, as more of us are working from home and need all the email protection we can muster.
Like much in the IT world, there are multiple solutions and they are quite complementary to each other. Chances are good that the average business is going to need to use 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 content of your emails remains trusted and hasn’t been tampered or compromised.
- Domain-based Message Authentication, Reporting and Conformance (DMARC), which ties the first two protocols together with a consistent set of policies.
These three protocols also complement the actual email message encryption, which is handled by another series of protocols, such as what Network Solutions sells with its business email that comes with Guard Encryption.
Reasons Behind the Three Protocols
Part of the reason for the three different protocols has to do with the fact that each one is solving 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.
Another part of the reason has to do with the evolution of the Internet email protocols themselves. Back in the early days of the Internet, it 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.
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 couple of years, the trio of protocols has gotten more attention because of several factors. First, spam and spear phishing continue to be issues, and as more networks get compromised because of them, IT managers are looking for better security solutions. Second, the feds have gotten involved and the Department of Homeland Security issued an order 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 spent a lot of time implementing the trio too across their hosted email solutions, because they want to keep their customers protected. Finally, there are some decent protective products and SaaS tools that can be used to implement these protocols. Vendors such as Valimail, Agari, Barracuda and others are gaining traction.
Here Come Some Complications
So that is all good news. Let’s look at the complicating factors.
First are the disappointing usage surveys. While a survey from 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 report from consultancy 250ok analyzed 21,000 of the top global domains and found that only 20% have deployed any of the three protocols. This agrees with another survey from Agari, which shows that only 15% of the F500 use DMARC properly, although the number has doubled from a year ago. (See chart taken from their report below.)
Next, setting up DMARC et al. is not easy, and subject to a lot of operator error. For example, for SPF and DMARC to work, you have to set it up for every domain — and subdomain — that you own. If your company operates a lot of domains or subdomains, the setup can get tedious very quickly. And 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 some instructions about DKIM here and about how to generate your domain key here. If you are using cPanel to manage your domain, here are some suggestions on how to configure the various DNS records. Once you think you are done, you can use this 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 some very specialized skills. Even your corporate DNS guru may not be familiar with the commands required by each protocol, not because of lack of knowledge but because these commands aren’t widely used and their syntax can be maddening to get exactly right.
Next, you should set 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. And 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.
Finally, you need to track down all of your apps that consume email. When you first begin implementing these protocols, you may not realize how many different parts of your own infrastructure interact with your email system. For example, you may use WordPress as your blogging server, which sends email notifications of various kinds and from different plugins. It could take you 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 of them may 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 required to complete the project.
NetSol sells Business Email that comes with Guard Encryption.