Domain Keys Identified Mail (DKIM) is a specification for cryptographically signing email messages, permitting a signing domain to claim responsibility for a message in the mail stream. Message recipients (or agents acting in their behalf) can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.

An explicit goal of DKIM is to be minimally disruptive to existing email users. Unexpected changes to message appearance or functionality would likely result in confusion among less-sophisticated users and reluctance to deploy on the part of signing domains. As a result, the signature itself is a field in the message header, where it is not normally visible in most mail user agents (MUAs) unless requested. Under most circumstances, DKIM signatures are applied and verified at the domain level so that individual users do not need to implement DKIM other than possibly to act on the results of message authentication performed by their domains. DKIM is intended to be complementary to (and can be used with) existing message security technologies such as PGP [RFC2440] and S/MIME [RFC3851].

DKIM makes very carefully considered compromises between robustness and the brittleness of cryptographic signatures in environments, such as email, where the material being signed is subject to possible modification en route. Common, innocuous modifications such as changing the end-of-line wrapping can be accommodated through the use of a canonicalization algorithm that removes such spacing features from the input to the signature calculation. DKIM also allows the signer to specify particular message header fields as part of the signature, bypassing others that may be modified in transit. These robustness features are available for use at the option of the signer, which can nevertheless choose not to permit such modifications as appropriate for the application.

Another approach to robustness in DKIM is for the modifier of a message to re-sign the message following the modification. This would typically be the case for mailing lists and commercial services that add advertising, mailing list instructions, or other material to messages. These "third-party" signatures take advantage of trust that certain known third parties will sign only messages that have been legitimately introduced into the mail system.

While provisions have been made for a number of key management systems, the initial key management that has been defined for DKIM is through the use of TXT records stored in the signer's Domain Name System (DNS) hierarchy. The location of a key record is specified by a "selector", an arbitrary name for the key and associated information. For example, if example.com uses the selector named "march2007", the public key would be obtained by retrieving the TXT record from march2007._domainkey.example.com. In addition to the public key itself, the key record contains information such as the algorithms that are used to calculate the signature. This is intended to guard against downgrade attacks, should any of the algorithms currently in use be insufficiently secure at some point in the future.

It is recognized that DNS is not currently a secure key distribution mechanism. While in the longer term DNSSEC [RFC4033] holds the promise of improving that situation, possible DNS attacks such as cache poisoning and name chaining [RFC3833] currently limit the security that is available through DKIM. However, the choice of DNS greatly enhances deployability by not introducing a new public-key infrastructure.

Many email applications depend on the ability of a sending domain to authorize external parties to send email on their behalf. This is frequently done by enterprises that outsource some of their services, such as technical support, benefits, and company newsletters. DKIM provides several different ways of delegating signing authority to such parties. One approach is for the external party to provide a public key that the domain registers by creating a selector for it. If desired, the validity of the key can be restricted to particular addresses within the domain through the use of a tag in the key record. Signing authority for a given domain can also be granted by using NS records to delegate the entire _domainkey subdomain. This might be done to permit keys to be managed directly by an external entity, such as an email service provider, or an internal one, like a separate IT messaging organization.

Within the IETF, the DKIM base protocol specification [DKIM-BASE] was approved by the IESG as a standards-track RFC in February 2007, and publication is expected in the very near future. An analysis of threats relating to DKIM [RFC4686] has also been published.

The IETF DKIM Working Group is continuing to develop guidance on deployment and usage of DKIM. A related protocol, Sender Signing Policy (SSP), is under discussion that would allow a sending domain to publish information about its usage of DKIM. SSP will allow domains to publish assertions such as, "we sign all messages leaving our domain" which may be useful information to verifiers receiving a message from that domain which lack a valid DKIM signature.

DKIM is a valuable tool in the fight against malicious email. While not a complete solution to spam and phishing, the existence of a verified indication of the source of email messages is an important tool enabling reputation, accreditation, and whitelist systems to aid in more accurate message evaluation. A number of commercial and open-source products have already implemented DKIM, greatly facilitating its deployment. Several large domains are already using DKIM, and DKIM signatures are appearing in email messages in ever-greater numbers.

For more information on DKIM, please consult the DKIM website at http://dkim.org or contact Jim Fenton (fenton@cisco.com).