Make your emails more trusted with DKIM

Here’s how to set up DKIM and DomainKeys on Windows Server machines

email thinkstock

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.

1 2 Page 1
Computerworld's IT Salary Survey 2017 results
Shop Tech Products at Amazon