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:


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

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 9:40 AM PST

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


Industry Updates – Sponsored Posts

Afilias Supports the CrypTech Project - Ambitious Hardware Encryption Effort to Protect User Privacy

Public Sector Experiences Largest Increase in DDoS Attacks (Verisign's Q4 2014 DDoS Trends)

NSW Government Launches .sydney Domain

New .VOTE and .VOTO Domains Now Available

Help Ensure the Availability and Security of Your Enterprise DNS with Verisign Recursive DNS

Verisign iDefense 2015 Cyber-Threats and Trends

Verisign Launches New Monthly Blog Series: Top 10 Keywords Registered in .COM and .NET

.LGBT Public Launch Begins Today

Verisign Celebrates .com's 30th Anniversary, Launches Domain Name Contest

What's in Your Attack Surface?

New .LGBT Domain Sunrise Period Begins

Minds + Machines in 2014 and 2015

DNW Podcast Interview with Antony Van Couvering

TLD Registry and Right of the Dot Establish a Domain Name Industry "Dream Team"

"Chinese Domaining Masterclass" to be Presented at NamesCon Las Vegas in January 2015

Q3 2014 DDoS Trends: Attacks Exceeding 10 Gbps on the Rise

LogicBoxes Announces Automation Solutions for ccTLD

TLD Registry Wins Best Marketing Award at China New gTLD Roadshow

Video Interviews from ICANN 51 in Los Angeles

Update on Minds + Machines' Top-Level Domain Launches

Sponsored Topics


DNS Security

Sponsored by
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines


Sponsored by


Sponsored by