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.