Home / Blogs

How Hard Is It to Deploy DKIM?

It’s coming up on two years since the DomainKeys Identified Mail (DKIM) standard was published. While we’re seeing a certain amount of signed mail from Google, Paypal, and ESPs, there’s still a long way to go. How hard is it to sign your mail with DKIM?

The major hurdle might seem to be getting mail software that can sign outgoing mail. Most free and commercial software now offers DKIM support, so that’s typically a routine software upgrade or add-on. (See this list for some examples.)

The other hurdle, which is now looking harder than the mail software, is setting up the signing and verification keys. A DKIM signature requires a private key used by the signing software, and a corresponding public key placed in the DNS for recipient systems to use to validate the signatures.

Creating the keys is straightforward in principle if not always in practice. Each key needs a 256 bit RSA public/private key pair. A common way to create it is with the popular freeware Openssl package, which in the classic open-source tradition, is very powerful, bristling with features and options, and baffling to the new user. Generating the keys only takes two commands with three options, but the trick is to know which ones they are. I wrote a small perl script that runs the appropriate openssl commands and reformats the output into the format for the private key as a file the signing software can read, and the public key as a record to add to my DNS server. It wasn’t a very hard script to write (given that I have 40 years of programming experience), but I did have to write it. Some of the mail server DKIM support software has the key generation build in, but not all of it does. It wouldn’t be hard to write a web based “wizard” to create the keys, although users would have to trust that whoever was running the wizard wouldn’t keep a copy of the the keys to use for nefarious purposes.

Once the keys are generated, the last step is to put the public key record into the DNS. This again is simple in principle but can be surprisingly hard in practice, particularly when the DNS server is fronted by a web based provisioning system, or the mail and DNS servers are managed by different mutually hostile groups.

Most DNS software reads the records from files in a textual format similar to the master file format described in 1987 in RFC 1035, like this:

k0903._domainkey.taugh.com. IN TXT “v=DKIM1; h=sha1:sha256; p=MIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoLLTbRvOcbGSFujXff4R08XXMxE5kJhFpIxBd/n /O7+YOTfg7lUWO8D14J6bXfOC0Bm93WHj1Dj3yXfJ/QTO5TjcmsjBNwW/XItJ4dFnEHWUg 6Ta8g7intJMtdVvMjW86/LpmFy/x3wxtHrbzifbjh0hxi54pAsCeIRuhfWyeKQIDAQAB ;”

(This is all on one line in the file; it’s folded here to fit in a screen width.) For provisioning systems with access to the files, all they need to do is to add the record to the end of the file. But web provisioning systems add extra problems. The first is that some of them don’t handle TXT records at all. All you need to handle mail and web servers are A records, for the servers’ addresses, and MX records for the names of the mail servers, and perhaps CNAME records to alias equivalent domains together, so that’s all the provisioning software handled. Since DNS servers tend to reject an entire file of records if any have syntax errors, the provisioning system needs to do careful syntax checking, and it’s understandable that there’d be little interest in writing checking code for records that weren’t likely to be used. Fortunately for DKIM, vast numbers of domains have published records for SPF or Sender-ID path authentication, and those are also TXT records, so by now it’s rare to have a system that can’t handle TXT.

The next problem is the record name. All DKIM records include the name component _domainkey to prevent accidental collisions with names used for other things. DNS names with underscores are deliberately second-class citizens; they can’t be used as the names of hosts in A or MX records, although they can be used for many other kinds of records. SPF didn’t use an underscore name (one of its more severe design errors), and names of web and mail servers can’t have underscores, so again, provisioning systems often don’t handle them. It’s not a hard thing to fix technically, but it’s at least a software upgrade or patch.

A subtle problem with provisioning relates to record lengths. Text strings in TXT records are limited to 255 chararacters, because they’re stored with an eight-bit length field. A TXT record can contain more than one string, and the DKIM spec says that multiple strings are OK, but not all provisioning systems handle that. In the example above, the string is 243 characters, so it wouldn’t take many more options to blow past 255.

Finally, DKIM keys are supposed to be rotated every once in a while, switching to a new selector (the part in the name before _domainkey) and a new pair of keys. I do it once a month, which is probably overkill, but rotating them at least once or twice a year is good practice.

Rotating keys is a three phase project. First, a few days before the planned key change, the new keys have to be generated and added to the DNS servers, to give them time to propagate to secondary servers and become visible throughout the DNS. Then, on the day of the key change, the signing software needs to switch to the new selector. Finally, a week or so later after all of the mail with the old selector has either been delivered or bounced, the old keys are removed from the DNS. Again, none of this is conceptually difficult, but someone has to remember to do it, and if the keys are only rotated once a year, it’s hard to remember what one did (or one’s predecessor did) last time. My perl scripts to do it all automatically, but this is a level of automated DNS management that’s somewhat beyond what’s usually handled now.

I think these are the main problems with DKIM provisioning, but I invite reports from other people who’ve done it, particularly if you’ve run into other problems.

By John Levine, Author, Consultant & Speaker

Filed Under


What if DKIM will fly? Alessandro Vesely  –  Mar 25, 2009 9:37 AM

Perhaps I’m out of luck, but the software list you mention fails to include my favorite MUA as well as MTA. I guess that’s because they are both GPLv3 licensed. I don’t know if the “classic open-source license” legend item in that list explicitly refers to obsolete licenses, but the IPRs clearly say “GNU General Public License v2.0 (and no other version).”

Patent encumbrance is possibly something more than just one more hurdle, because it has been placed there by purpose. Patents are one of the reasons why GPL has been upgraded to version 3, so I’m not that confident that there will be no surprise in case DKIM will take foot. What can the risk be, if DKIM will fly?

Good article John. My only quibble is Michael Hammer  –  Jun 23, 2010 5:40 PM

Good article John.

My only quibble is the amount of time (a week or so) you suggest for the key overlap. If key validation is only occurring at the MTA (Mail Transport Agent) then this is probably a sufficient amount of time. If and when there is greater implementation at the MUA (Mail User Agent) then a longer overlap is more appropriate. This will ensure that messeges validate appropriately in less frequently checked mailboxes.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix


Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC