PGP CTO Blog

DKIM provides a way for an email message to be signed so the receiving domain can know the sending domain, even if it has been forwarded through intermediate domains. It is an important part of email infrastructure that is already being used to solve spam and email fraud. We have also been careful to make it upwards-compatible from the original DomainKeys system.

The cross-industry group working on DKIM includes Alt-N Technologies, AOL, Brandenburg Internetworking, Cisco, EarthLink, IBM, Microsoft (both the Exchange group and the Hotmail group), PGP Corporation, Sendmail, StrongMail Systems, Tumbleweed Communications, VeriSign, and Yahoo!. We want DKIM to be an approved international standard, not simply a de facto standard, so we are submitting the draft specification to the Internet Engineering Task Force (IETF) this summer.

Why create a new standard?
How DKIM works
False dilemmas, false competition
Building on authentication
How to get involved
Background reading

Why create a new standard?
Given that there are two existing standards that allow for email signing, OpenPGP and S/MIME, why did we create something new? The reason is that there are characteristics we want this system to have that are best addressed by a new system:

End-user transparency. We want there to be no required changes to existing email clients and no required changes in what a user sees. This characteristic is extremely important because there are many email clients, and not all of them have regular schedules for updates. It is much simpler to put the necessary changes in the servers and then add features to the clients. However, we also want to permit email clients to add in indication of DKIM-signed messages. Yahoo! is already doing this in its webmail systems, noting when a message has been authenticated.

Similarly, we don't want the users to see anything new. This is particularly important to Internet Service Providers (ISPs) that don't want to answer support calls from users asking what the changes to their email mean. Users shouldn"t be surprised.
No user intervention. We don't want to require end users to do anything. Even worse than surprising them with changes would be to require them to learn to do something new. That requirement would doom the system to failure.
Signatures identify sources. We want a system that does not create issues about the meaning of the signatures on the message. If I send you a signed postcard from vacation, you know my signature is a personal touch, not a legal commitment to, “Having a wonderful time, wish you were here.” That same signature at the bottom of a business letter means something very different.

A DKIM signature means the message came from a specified source, and nothing else. It is metaphorically more like a postmark on an envelope than the signature on the letter inside the envelope. Each of these has value, but on different levels. The email delivery system does not (and should not) care about the internal signatures on the content, and the systems that work with signed content do not and should not care about the signatures that cover delivery.
No certificates. For simplicity's sake, we want a system that does not require a certificate system. There is value to having the keys that sign DKIM messages be part of a PKI, but it is not necessary. The signature simply covers the message transport, its metaphorical “envelope.” We want these keys to be easy to create, update, maintain, and expire. Note that this does not preclude using a certificate system as an adjunct to DKIM. There are reasons to have certificates, too. We just don't want them to be required.
Privacy-friendly. We don't want to create new privacy concerns in an anti-spam system. DKIM signatures are by and about an administrative domain, not about the end user. A DKIM signature denotes that the end user was authorized to send that mail and takes responsibility for it, but nothing more. The end user may not even be an actual person, but an administrative process.

Consequently, we are using a different formatting system that unambiguously shows which signatures mean what and allows for content-signature systems such as OpenPGP and S/MIME to work with DKIM. Had we adapted one of the previous systems, we would have had to expend a lot of effort working on mixing and disambiguating the different signatures and what they cover and mean. Because DKIM signatures are used differently and mean different things than content signatures, it is best if they are a separate system.

How DKIM works
DKIM's basic operation is simple. Before a mail transport system sends an email, it creates a digital signature of the message and some set of its headers. That signature and a description of what is being signed are put into the message's headers.

DKIM is also upwards-compatible from the original DomainKeys system. DomainKeys is already being used by a number of ISPs and email senders, including Gmail, Yahoo!, and others. Look through your mailbox and see if you have a message from them, and then look at the headers. You"ll see the DKIM signature there.

When the message is received, the public key for the message is retrieved from DNS for the signing domain. The receiver verifies the signature and then processes the message.

DKIM also includes policy components, which are rules about how the signatures are to be used. For example, a signer can state, “I sign all my messages, and if you find an unsigned message that claims to be from me, reject it.” These policy components help signing domains tell receiving domains what to do with the messages.

False dilemmas, false competition
Unfortunately, there has been and still is a good deal of misunderstanding about DKIM and other technologies that are positioned as false competition. Now that we have released the first integrated DKIM specification, there will no longer be discussions about DomainKeys versus Internet Identified Mail. However, there is still false competition between DKIM and SenderID.

SenderID is a unification of Sender Policy Framework (SPF) and CallerID that is similar to the unification of DK and IIM into DKIM. It is a path-based form of authentication. In SenderID, a domain states which host addresses it will send mail from, and thus allows the receiver to know something about the message"s authenticity based on its network source, rather than its content.

Some people still look at email authentication as a competition, rather than as the coexistence of complementary technologies. SenderID and DKIM work well together, in fact, better than either works alone. It is valuable to have both network-level, path-based authentication as well as signature-based authentication that travels with the message even as it is routed. The situation isn't “either-or,” it's “both-and.”

Building on authentication
Authentication is part of the system, but it isn"t the whole story. Traditionally, security includes not only authentication, but authorization as well. Authentication tells us who an entity is, and authorization tells us what that person is allowed to do. For example, a keycard entry system may not let you through a given door, even though it knows who you are. After your bank has authenticated you, you are still authorized to spend only the money in your account. In the case of email, authorization is somewhat vague: it refers to who is allowed to send you mail. Amazon is more likely to be authorized to send you mail than Miriam Abacha of Nigeria, for example.

In email security, we're phrasing authorization issues as reputation issues: Who is that sender and how likely is it the end recipient wants to see that message? Neither the DKIM nor SenderID authentication system has built-in authorization and reputation. However, both permit authorization systems, reputation systems, blacklists of known bad senders, and whitelists of known good senders to become far more effective. Although it's possible for bad senders to authenticate their email, fighting spam from authenticated spammers is much easier.

Beyond this, authentication permits other sections of the Internet infrastructure to become involved. Part of the problem in email security is that the bad actors buy many domains and use them to send bad email. Authentication allows us to start tying the bad actors to their bad email, while protecting the good actors.

How to get involved
As I mentioned earlier, DKIM is upwards-compatible from DomainKeys. If you run email systems, consider running DomainKeys now so you can start getting used to this process. If you don't want to run it, at least look at DomainKeys because it will give you an idea of what is to come.

If you are adventurous, look at the existing DKIM implementations. We already have three interoperable implementations of DKIM, from Alt-N, Cisco, and Sendmail.

If you use email systems, encourage the people who run your email systems to start looking at DomainKeys or DKIM. Although DKIM is not yet available for everyone to deploy, it is worth planning what you will do because email authentication is here even if it isn"t yet complete.

If you don't want to implement anything yet, but you want to be prepared, start examining your email infrastructure. Examine which systems will send email on your behalf. Examine how off-site employees, contractors, outsourced business partners, and other people use email that comes from your domain. Whether you use SenderID or DKIM, you need to know who is sending mail on your behalf. After that, you need to find where email is being received. The latter task is easier, but each can have surprises.

Everyone's email infrastructure is set up ad-hoc and works in ways its staff doesn't know--a result of the nature of email. Authentication is going to force users to figure out how email is set up. Authentication is good for everyone because it will finally make a dent in spam and phishing, but it also means that we have to understand our email systems, which we never had to do before.

Background Reading

“DomainKeys Identified Mail (DKIM),” 2005

Evers, Joris, “Antispam spec sets off on path to standard,” July 11, 2005, CNET News.com

Yahoo! Anti-Spam Resource Center, “DomainKeys: Proving and Protecting Email Sender Identity”

PGP News Feed