Make your emails more trusted with DKIM

The war against spam has been a long one. Just as we get better filtering, spammers and phishers turn to more sophisticated techniques. We are even seeing ransomware attacks like Cryptolocker and Cryptowall become commonly spread over email. There must be a technical way to stop some of this, right?

There is an Internet authentication system — DomainKeys, and its successor, DKIM — that tries to mitigate some of the risk of trusting that emails are actually from who they say they are from. Strangely, though, this technology has not made its way into Microsoft Exchange. In this piece, I want to open the curtains on DomainKeys and DKIM, show how they work and why what they do is important, and then demonstrate how to use a free utility to set up DKIM on your on-premises Exchange servers.

A brief history of DomainKeys and DKIM

It all started back at Yahoo. (Yes, that is correct — Yahoo was on the forefront of something other than Tumblr and micro acquisitions. Of course, lots of big data technology started at Yahoo — so I guess it is not a wasteland of tech heydays gone by. But I digress.)

In 2007, Yahoo, which was still a big email service provider, was looking for a way to further clamp down on the immense amount of spam it had to deal with. What if there were a way to use domain names and specialized DNS records so that senders could verify that they actually sent a piece of mail — as opposed to spammers and phishers inserting a legitimate email address into a message without the authorization or permission of its owner. Enter DomainKeys.

With DomainKeys, the owner or registrant of a domain generates an encryption key pair — one public key and one private key — and puts the public key in a special TXT record within its forward lookup zone at its public DNS server or servers. The private key is stored on the mail server and the server signs every outgoing message it sends with that private key. It adds that digital signature to a header within the email message, just like all of the other header information: sending server, all of the hops in between, date and time, mail client, antivirus updates, etc.

When the receiving mail server sees an inbound message from a domain, it checks that domain’s public DNS zone and retrieves the public key for that domain. It then authenticates that public key with the private key with which your server signed the outgoing message. If it matches, then there is an extremely high probability that the message is authentic.

Why does this keep spammers and phishers away? If you protect the private key that is stored on your mail server and it is never compromised in any way, then spammers, phishers and other ne’er-do-wells will not be able to send messages signed with your correct private key. When messages do not correspond with your public key, legitimate recipients will be highly suspicious that those messages that they cannot authenticate are indeed spam.

Yahoo took DomainKeys and published it as an RFC. The standard was made better in the following years by coupling the groundwork Yahoo laid with some improvements from Cisco and its proposed Identified Internet Mail standard. All of this merged to become an Internet Engineering Task Force standard called DomainKeys Identified Mail, or DKIM. People still use the terms interchangeably, though the latest iteration of all of this technology that folks should use is technically DKIM.

DKIM adds a few things onto the base DomainKeys, like multiple algorithms for generating signatures on mail, delegation ability in case you have outsourced your email, signing the DKIM-Signature header field itself to defend it against being modified somewhere else, and supporting timeouts so the whole thing does not fall over if there is a hiccup in internet access or availability.

Behind the DKIM signature

The most important element in DKIM is the signature applied to outbound messages. Here is what a typical DKIM signature looks like, picked up from my test bed mail server, which I formatted to bare metal.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.82ventures.com; s=mail; t=1417816294;

bh=Gkyz0VQ/wwtSLeyhB0FWela3EE0z1Na71VTmcbws6/4=;

h=From:Subject:Date:References:To:In-Reply-To:From;

b=IsgK7KFVE1XfQ5veuXuVL1Q38aUhx4BoAhGYHtT7UZMS4hLC/hkhOSht6Y//LKjYo ZDY7X2KUaTJM3xDHlROph2hVfB+rl1yx2e+ko89wY8+uV3C6zB60mEY0GH3oUY5II7 UCBalrVUnwARvMLe/1Ewd89N6tVajUnznkyB1ohI=

You will immediately notice that the whole signature content consists of a bunch of fields: a = b, c = d, and so on. Here is what they all mean:

• v is the version of the DKIM being used.
• a is the algorithm used to generate the signature.
• c refers to the canonicalization of the header and body of the message, with the header listed first and then the body. This is basically DKIM lingo for how the header and the body are given to the signing algorithm to get a signature applied. You do not typically have to worry about this setting.
• d is the domain being signed for.
• s is the selector — this is usually the hostname of the mail server of the selected domain ‘d.’
• t is the timestamp of the signature, in ancient UNIX format.
• bh is the hash of the body part of the message.
• h is the list of headers that DKIM is signing.
• b is the actual digital signature of the whole message.

Remember, this is the signature that is on the actual email message.

The next most important element is the public key that is stored in the DNS zone file for any given email domain. When the inbound server receives this mail, and it is configured to look for DKIM information, it is going to immediately perform a DNS lookup for the TXT record of the “d” domain and specially the “s” selector of that “d” domain. For example, in the above signature, the receiving mail server (in this particular case it was Gmail) performed a DNS TXT record lookup for mail._domainkey.example.net.

What does this type of query return? Let us take a gander at how mass mailer Infusionsoft sets up DKIM on their side as far as their public DNS record goes. I looked at a message sent to me by Infusionsoft with the following DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha1; d=infusionmail.com; s=dkim1024;

c=simple/relaxed; q=dns/txt; i=@infusionmail.com; t=1422548837;

h=From:Sender:Subject:Date:To:MIME-Version:Content-Type;

bh=UhrArJqPOZZAmglXYR/w5jUlsL4=;

b=Dt3hbPAeUZMHVXesCjv94Rz49GB8VWIjie1LIAp1zQ3bNld5j399VXhjpwpfSeud hyDKc0hZYviiRJ/QGo3q0DtOe87DyaE2SIlNbZ0uzXyMSIsArm1oDemmnuqxESHx cSZ9p1abToV4UWSxm4OZ5Kuqkvf02GcgNf5Tu/CVppo=;

We can see that the selector (the “s” field) is dkim1024 and the domain (the “d” field) is infusionmail.com. So I can open up nslookup at the command line of my workstation, set the record type I want to query to TXT, and then look for dkim1024._domainkey.infusionmail.com. That is shown below.

Jonathans-iMac:~ JonathanHassell$ nslookup

> set type=txt

> dkim1024._domainkey.infusionmail.com

Server: 192.168.82.5

Address: 192.168.82.5#53

Non-authoritative answer:

dkim1024._domainkey.infusionmail.com text = "v=DKIM1; k=rsa; h=sha1;

p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDU3/M4D+rH3s0jPoeuUzaok1NiH+UqxBqtPw2qYdOP7omHiOvM6OAdyWqIfHga8cB6NjgcS8eXCMt1GfcJs5Fn/pdVB2FqfyW7S9Te/Icfrdz45L6PVOT1jJ9S6JSvEme/xNN1SSj1YHAa5ZwTYBHuBJxcGEyvta91Sf8bNrwU1wIDAQAB"

Authoritative answers can be found from:

>

You can see that the DNS record is basically just the public key. The inbound mail server grabs that public key, matches it up with the signature in the DKIM-Signature header, and attempts to authenticate it. If it works, it is probably a legitimate message. If that matchup is unsuccessful, there is a high degree of likelihood that the message is spam.

Getting DKIM set up with Microsoft Exchange Server

Microsoft’s Exchange platform is pretty much the de facto standard in corporate email around the world. If you have not moved email to the cloud with Office 365 or another provider, and you are not stuck on Lotus Domino, then you are almost certainly using Exchange if you are in a corporate setting.

For some reason, however, Exchange Server (all the way up to the current version, 2016) does not have the ability to sign messages a la DKIM. Since Exchange Server has been around in various flavors since 2007, you would think this would have happened by now — but it has not. Ultimately, this means you need a third-party utility to get DKIM support on your Windows and Exchange servers. That is where a recent open source project called DKIM-Exchange comes in.

DKIM-Exchange — or more formally, the DKIM Signing Agent for Microsoft Exchange Server — is available on Github and is a community-provided solution for signing outgoing emails from Exchange Server according to the DKIM specification. The agent works with .NET Framework 3.5 and the following Exchange versions, including service pack levels:

• Exchange 2007 SP3 (8.3.*)
• Exchange 2010 (14.0.*)
• Exchange 2010 SP1 (14.1.*)
• Exchange 2010 SP2 (14.2.*)
• Exchange 2010 SP3 (14.3.*)
• Exchange 2013 (15.0.516.32)
• Exchange 2013 CU1 (15.0.620.29)
• Exchange 2013 CU2 (15.0.712.24)
• Exchange 2013 CU3 (15.0.775.38)
• Exchange 2013 SP1 (15.0.847.32)
• Exchange 2013 CU5 (15.0.913.22)
• Exchange 2013 CU6 (15.0.995.29)
• Exchange 2013 CU7 (15.0.1044.25)
• Exchange 2013 CU8 (15.0.1076.9)
• Exchange 2013 CU9 (15.0.1104.5)
• Exchange 2013 CU10 (15.0.1130.7)
• Exchange 2013 CU11 (15.0.1156.6)
• Exchange 2013 CU12 (15.0.1178.4)
• Exchange 2013 CU13 (15.0.1210.3)
• Exchange 2013 CU14 (15.0.1236.3)
• Exchange 2016 Preview (15.1.225.17)
• Exchange 2016 RTM (15.1.225.42)
• Exchange 2016 CU1 (15.1.396.30)
• Exchange 2016 CU2 (15.1.466.34)
• Exchange 2016 CU3 (15.1.544.27)

Note: Office 365 rolled out validation of DKIM signatures on inbound messages in January 2015. At this point, Microsoft has no plans to enable native DKIM in on-premises versions of Exchange.

In this section, I will walk through how to get this set up on your Exchange server.

First off, download the GUI package zip file — you’re looking for the file called Configuration.DkimSigner.zip. Extract the contents of the file, then start the program you see as a result — which is named Configuration.DkimSigner.exe — and select Install. Select the latest non-prerelease version of the utility, and then click Install.

Once the installation is finished, you’ll want to launch the configuration utility, which you’ll find at C:Program FilesExchange DkimSignerConfiguration.DkimSigner.exe. The GUI utility has five tabs: fcanoInformation, DKIM Settings, Domain Settings, EventLog Viewer and About. You’ll primarily be messing around with the DKIM Settings tab and the Domain Settings tab.

On the DKIM Settings tab, you can configure which mail headers to sign, including From, Subject, To, Date and Message-ID. You can also choose the algorithm, the level of logging to the event log, and the way the headers and body information are canonicalized. For most organizations without specific requirements — and if you have them, you know who you are — I would leave most of these as their defaults.

On the Domain Settings tab, you will add the domains for which outbound messages should be signed. Click the Add button at the lower left corner, enter the domain name and selector, and then click Generate New Key. The system will populate a suggested DNS name and record for you, and then will also do a current DNS lookup so you can see what the current record is for that domain. Using whatever DNS editing system you have, update the DNS name and record with the agent’s recommendation, and then click Save Domain.

To make sure everything is working, send a test message. If you are sending these test messages to Google, the way to check if DKIM is configured and working right is to find the Authentication-Results header. Here is an example:

Authentication-Results: mx.google.com; spf=pass (google.com: domain of mailer@infusionmail.com designates 208.76.24.57 as permitted sender)

smtp.mail=mailer@infusionmail.com; dkim=pass

header.i=@infusionmail.com

The important bit there is the “dkim=pass” notification. If you see this, the authentication was successful and you have done everything you need to do. Most other email headers from other service providers will have some sort of acknowledgement that the DKIM signature was verified.

You can also send a mail to mailtest@unlocktheinbox.com and the system will immediately reply to you with the results of the DKIM check.

The last word

If you run a mail server these days, it is very important that you use every tool at your disposal to sort the wheat from what has become very dangerous chaff. DKIM in your Exchange environment is one way to do this. Start today.

RELATED VIDEO: