Home / Blogs

How Hard Is It to Deploy DKIM?

Don't miss a thing – sign up for CircleID Weekly Wrap newsletter delivered to your inbox once a week.
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



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

Explore Topics

Sponsored Topics

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Leading Internet Associations Strengthen Cooperation

5 Afilias Top Level Domains Now Licensed for Sale in China

Radix Announces Largest New gTLD Sale with Casino.Online

2016 Year in Review: The Trending Keywords in .COM and .NET Domain Registrations

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

A Look at How the New .SPACE TLD Has Performed Over the Past 2 Years

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

MarkMonitor Supports Brand Holders' Efforts Regarding .Feedback Registry

Don't Gamble With Your DNS

8 Tips to Find Your Perfect .COM Domain Name

Why .com is the Venture Capital Community's Power Player

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

New TLD? Make Sure It's Secure

Radix Launches Startup League at TechCrunch

Celebrating One Year of .online