Home / Blogs

Searching for Truth in DKIM: Part 1 of 5

DomainKeys Identified Mail (DKIM) is the leading email authentication technology, supported by major ISPs including Google, AOL, and Yahoo! (who invented its predecessor), popular mail server software like Sendmail, and many of the best minds in email technology. But if you peruse the archives of the IETF DKIM mailing list, or start up a conversation at MAAWG, it might appear that there’s still a lot of disagreement about what a DKIM signature actually means.

Often, anyone attempting to describe authentication turns to analogies: a driver’s license, or a license plate on a car, or a passport—all saying that you are who you say you are, but not (by themselves) proving that you’re trustworthy. The trust measurement is external to DKIM: a reputation score, or third-party certification status.

But what, exactly, is being trusted? What’s being measured? An email message cannot contain the soul, or even the full identity, of the person or company who sent it. Reliably tying a message to the actual entity, the actual author, can be extremely difficult.

Security geeks talk instead about an identifier: a symbol that establishes the identity of the one bearing it. Here’s where the analogies work: a passport or a driver’s license is an identifier you can carry in your pocket, while a license plate is an identifier attached to a vehicle and backed by registration records.

In email, the ideal identifier would establish, beyond any doubt, the identity of the author of the message. Without DKIM, the closest we’ve been able to get is to determine the IP address which transmitted the message, after which we have to make assumptions about the owner of the IP address. DKIM is a vast improvement, establishing the domain name which signed the message. And the domain name, itself, is an identifier which can be tied to the company or person who registered that domain name—it’s attached to an email message or web site, and is backed by registration records, just like a license plate.

Sometimes—particularly for commercial mail—the domain name is equivalent to the author. Those messages were sent by the company who registered the domain name. That’s enough to tie the social reputation of the company to the message: if you trust your bank, you’ll trust messages that you are certain were sent by your bank. And DKIM gives us this certainty—almost.

Thing is, the identifier used in DKIM is not the domain name of the author of the message. Instead it’s a new value called “d=”, which is (according to the DKIM specification) “the domain that will be queried for the public key” when verifying the cryptographic signature at the core of how DKIM works. To put it another way: d= identifies the domain name which signed the message, and that may be a different domain name from the author of the message.

The most common reaction, upon learning this, is for someone to say “well, then, DKIM is useless!” But, that’s not true at all. It’s simply that DKIM isn’t the end of the story. Once you’ve got an identifier you can rely upon, a myriad of other things become possible. We’ll discuss these further over the course of four more postings on this subject. Don’t touch that dial…

(This article was originally published by Return Path)

By J.D. Falk, Internet Standards and Governance

Filed Under


Terminology Jim Fenton  –  Mar 9, 2009 6:42 PM

I’m hoping not to create further confusion, but I’d like to pick at your terminology a bit.

Your driver’s license isn’t an identifier, it’s a credential.  The driver’s license number on it


, however, an identifier.  We had used the term “signing identity” in the specification, when arguably it should have been “signing identifier”.

A lot of the confusion about identifiers in DKIM stem from the flexible delegation capabilities that are built into it.  We provided mechanisms to simplify key management for domains with lots of subdomains (parent domain signing) and for fine-grained delegation of signing authority, so that a domain could give a third-party sender the authority to sign certain email.  It’s a little early to see how much these capabilities will be used, but we have done interoperability tests to make sure that they work.

Good points, Jim, and thanks for the J.D. Falk  –  Mar 10, 2009 10:27 AM

Good points, Jim, and thanks for the clarification…seems like a lot of the confusion starts with improper analogies.  I’ll be avoiding ‘em in the rest of this series.

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




Sponsored byDNIB.com

New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API