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)