Summary

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The IETF has now approved the DKIM specification as a Proposed Standard and published it as RFC 4871.

The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing".

Signing/Verifying Overview

Messages are signed using public key cryptography — currently only the RSA algorithm is defined. The signature is created and communicated as follows:

• The body of the message is canonicalized to prevent minor transmission modifications from breaking the signature, then hashed using (by default) SHA-256.
• The signer chooses the message header fields to be included in the signature.
• A new message header field called DKIM-Signature is then created which includes information about the canonicalization algorithms used, the list of headers signed, the name of the signing domain, the body hash, and a selector (essentially the name of a signing key; see below for details).
• The header fields being signed and the DKIM-Signature field itself are then canonicalized and hashed.
• An RSA signature is computed on that hash, and the signature is inserted back into the DKIM-Signature field.
• The full DKIM-Signature field is then added to the header of the message, and the modified message is sent.

Verifiers employ essentially the same process in reverse.

• Using the information from the DKIM-Signature header field, the verifier canonicalizes and computes the hash of the header fields that have been signed (being careful to remove the actual signature part of the DKIM-Signature header field before hashing).
• The verifier gets the public key from the alleged signer using a DNS lookup based on the domain and selector name in the DKIM-Signature header field, and uses that to verify that the signature in the message is legitimate.
• If the header has successfully authenticated, the verifier then canonicalizes and hashes the body of the message and checks to make sure that the body hash is the same as the body hash in the DKIM-Signature field.

Selectors

Selectors enable a single domain to have multiple keys. Multiple keys are useful for several reasons. Good security practice includes changing keys periodically (e.g., monthly or annually), and those keys will need to overlap for a period. For example, an organization might sign using a 2007 key up until December 31, and then switch to a 2008 key on January 1. However, messages sent late on the 31st might not be verified until sometime on the 1st, so the signer will need to maintain two keys for at least a few days.

Another good reason for selectors is outsourcing. An enterprise that outsources some business function might want that third party to sign messages so that they appear to come directly from the original enterprise. However, sharing private keys is a security risk, so the enterprise might create a special signing key specifically for its outsourcer (or even for a particular campaign from that outsourcer). The sponsoring enterprise would publish the public key using a uniquely named selector and delegate the private key to the outsourcer. If that key should become compromised or the particular campaign should end, the selector (and the public key) can be removed. When the public key is removed verifiers have no way to check a signature, so the private key becomes worthless.

Sender Signing Practices

When a particular sender has upgraded all of their outgoing mail systems to use DKIM, all of the legitimate mail sent from them will be signed. If a verifier had a way of knowing this, the verifier could infer that any unsigned messages were forgeries. Without such knowledge the verifier has to assume that an unsigned message is legitimate, since there is no requirement that the entire Internet immediately adopt DKIM.

Sender Signing Practices (SSP) is a way for legitimate senders to tell the world that they are signing all of their outgoing mail. It works much the same as the public keys: the sender publishes a DNS record in a known place in their domain space that announces to the world what their practices are. For example, a sender’s SSP might be "I don't sign all of my mail" or "I do sign all of my mail". The default is that the domain does not sign all outgoing mail.

Additionally, SSP can include some sender-discretionary information for use by the verifiers. For example, the sender might ask verifiers to discard any messages that are signed by someone else (third party signatures). This can happen when sending a message to a mailing list, for example. A domain that only sends transactional email (which should never be sent to a mailing list) might specify that policy.

The SSP specification is still being formalized in the IETF DKIM Working Group.