What are DMARC, SPF and DKIM? How to master email security with these protocols

Despite making some progress, a trio of email security protocols has seen a rocky road of deployment in the past year. Going by their acronyms SPF, DKIM and DMARC, the three are difficult to configure and require careful study to understand how they inter-relate and complement each other with their protective features. The effort, however, is worth the investment in learning how to use them.

What is SPF?

Sender Policy Framework (SPF) hardens your DNS servers and restricts who can send emails from your domain. SPF can prevent domain spoofing. It enables your mail server to determine when a message came from the domain that it uses. SPF has three major elements: a policy framework as its name implies, an authentication method and specialized headers in the actual email itself that convey this information. SPF was first proposed with IETF standard 4408 back in 2006, and has been updated most recently to standard 7208 in 2014.

What is DKIM?

DomainKeys Identified Mail (DKIM) ensures that the content of your emails remains trusted and hasn’t been tampered with or compromised. It was initially proposed in 2007 and has been updated several times, most recently with the IETF standard 8301 this last January. Both SPF and DKIM were updated with the IETF standard 7372 in 2014.

What is DMARC?

Domain-based Message Authentication, Reporting and Conformance (DMARC) ties the first two protocols together with a consistent set of policies. It also links the sender’s domain name with what is listed in the From: header and also has some better reporting back from mail recipients. It was proposed as an IETF standard 7489 in 2015.

Why you need DMARC, SPF and DKIM

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.

What isn’t as well known is why most enterprises need all three of these protocols to protect their email infrastructures. 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 them.

Recent developments drive interest in email security protocols

As you can see, all three protocols have been around for years. What has happened recently to renew interest?

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. With the rise in ransomware – which often is preceded by spear phishing emails – enterprises are getting more motivated towards protecting their email infrastructure. Certainly, spam is not going away.

Second, governments 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 also issued their own timetables to mandate deployment, at least on government-run servers. While many agencies didn’t meet the initial deadlines, many agencies have begun implementation and have made some important strides towards having a complete deployment.

Third, the implementations of email providers such as Google’s Gmail, Yahoo and Fastmail have motivated others to follow their lead. Adding these protocols across their hosted email solutions makes sense because the providers want to keep their customers protected.

Finally, security vendors have improved their products and consulting services to make deployment easier. Valimail, Barracuda and Agari are just three of many such vendors, and Proofpoint has a free interactive tool to create your DMARC record here. (Note: I tested Valimail on my own email infrastructure and used the experience in writing this report, as you’ll see in a moment.) Also of note: Agari, Valimail and Microsoft are behind a new standards effort called Brand Indicators for Message Identification (BIMI) that is off to a slow start. It will display logos on each email message, which could be useful for mobile email users (see mockup screen below) until spammers figure out a way around displaying phony logos.

Brand Indicators

Use SPF, DKIM and DMARC together

Let’s take a closer look at the three different approaches. First, why do we need all three? 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.

Second, we need three because of how the internet’s email protocols evolved. 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.

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.

That is all good news. Let’s look at the complicating factors.

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, where adoption rates aren’t anything to write home about. A new DMARC report by 250OK published in August 2018 shows that legal firms are leading the way – but still with only a third of them adopting the protocols. Most other firms had miniscule adoption rates, as you can see with this graph:

250ok

The 250OK study agrees with a earlier survey from Agari, which shows that only eight percent of the F500 use DMARC properly, and only two percent of total domains have any protection whatsoever. A Valimail report from March 2019 showed that 35 percent of global technology companies studied had properly configured DMARC, but did not set policies that would stop phishing via a spoofed From address. Only 10.5 percent of tech companies had properly configured DMARC and set policies to stop phishing via spoofing.

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 them 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 is to 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. 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.

LinkedIn’s engineering staff had recommendations on bigger-picture issues here, including how to set your corporate email standards to better secure your message traffic. While I don’t agree with all of them, they are worthy of review.

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, since they were being sent to my Spam folder. You too might have these hidden email applications that aren’t obvious and will require some additional effort.

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.