Home / Blogs

How Hard Is It to Deploy DKIM?

John Levine

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. More blog posts from John Levine can also be read here.

Related topics: Domain Names, Security, Spam

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

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

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 10:40 AM PDT

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.

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Independent Endorsement of Dot Chinese Online & Dot Chinese Website

ICANN London Recap Webinar

Four Reasons to Move from .COM to Your .BRAND Domain

DotConnectAfrica Delegates Attend the Kenya Internet Governance Forum

Introducing the New .ORGANIC Domain: A Trusted, Credible Space for Organic Products on the Web

.WANG - 15,000 Registrations on Day One of General Availability

Dot Brand: Why Your Brand Needs Its Own Top-Level Domain

Afilias Announces Start of .BLACK Sunrise Period

Radix Launches Three New TLDs in Sunrise With Backing from 50+ Registrar Partners

.WANG General Availability Opens on June 30, 2014

3 Questions to Ask Your DNS Host about Lowering DDoS Risks

Continuing to Work in the Public Interest

.Press Domain Names - The Changing Face of Journalism

Radix Announces .Website Launch Timeline

.Host Timeline Released As Pioneer Program Kicks Off

Verisign Named to the OTA's 2014 Online Trust Honor Roll

TLD Registry Sponsored Xinnet's Partner Conference in Nanjing

Victorian Government & ARI Agree to Long-Term .melbourne Partnership

.WANG Enters Landrush This Week

Public Interest Registry Offers New Internationalized Domain Names to General Public

Sponsored Topics