This list will continue to change, as you ask new and interesting questions and as better answers are developed.

• Basics
• Implementation
• Adoption and Deployment
• Technical Details
• Comparison with Related Technologies

• What is the purpose of DKIM?

DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. Their reputation is the basis for evaluating whether to trust the message for delivery.

• What does DKIM do?

The responsible organization adds a digital signature to the message, associating it with a domain name of that organization.  Typically, signing will be done by an service agent within the authority of the message originator's Administrative Management Domain (ADMD). Signing might be performed by any of the functional components, in that environment, including: Mail User Agent (MUA), or Mail Submission Agent (MSA), Internet Boundary MTA. DKIM permits signing to be performed by authorized third-parties.

• Who validates the signature?

After a message has been signed, any agent in the message transit path can choose to validate the signature. Typically, validation will be done by an agent in the ADMD of the message recipient. Again, this may be done by any functional component within that environment. Notably this means that the signature can be used by the recipient ADMD's filtering software, rather than requiring the recipient end-user to make an assessment.

• What does a DKIM signature mean?

The owner of the domain name being used for a DKIM signature is declaring that they are accountable for the message. This means that their reputation is at stake.

Receivers who successfully validate a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behavior, although the DKIM specification itself does not prescribe any specific actions by the recipient.

NOTE:

An interesting example of signature use is to detect email that purports to be from a user of the receiving site. If that site signs all its email, then incoming mail that purports to be from one of the site's users, but is not signed, is not valid.

• Will using DKIM improve my deliverability and guarantee that my marketing mail goes directly to the recipients' inbox, bypassing any spam filters?

Whether this improves deliverability or bypasses filters is entirely at the discretion of the validating receivers. When a message has been signed using DKIM, a receiver uses their knowledge about the signer to determine the most appropriate treatment of the message. It is expected that messages from a signer who has a good reputation will be subject to less scrutiny by the receiver's filters.

• What does DKIM not do?

Examples include:

• DKIM does not offer any assertions about the behaviors of the identity doing the signing.
• DKIM does not prescribe any specific actions for receivers to take upon successful (or unsuccessful) signature validation.
• DKIM does not provide protection after message delivery.
• DKIM does not protect against re-sending (replay of) a message that already has a valid signature; therefore a transit intermediary or a recipient can re-post the message in such a way that the signature would remain valid, although the new recipient(s) would not have been specified by the originator.

• S/MIME and OpenPGP also do email digital signing. Why not simply use one of them?

Unlike other mechanisms, DKIM satisfies the short-term needs of email transit authentication. This make it less costly to use. It also can be entirely invisible to end-users whose software does not support DKIM, whereas S/MIME and OpenPGP are quite intrusive. (An extended discussion of technical differences is in the Comparisons section, below.)

• DKIM is claimed to be an upgrade of Yahoo's DomainKeys. What is different and why should I upgrade?

DKIM is the result of a multi-company effort to enhance DomainKeys for broader adoption, better security, and more flexibility.

NOTE:

DKIM is upward compatible with existing DomainKeys DNS records, so that a DKIM module does not automatically require additional DNS administration!

A lengthy list of the technical differences is in the Comparisons section, below.

• What is DKIM's history?

DKIM was produced by an industry consortium in 2004. It merged and enhanced DomainKeys, from Yahoo! and Identified Internet Mail, from Cisco.

The resulting specification is in production use.

An IETF working group has standardized and refined DKIM.

• What software has to change, to use DKIM?

The signer needs to add code in the appropriate agent, to perform signing, and they need to modify their DNS administrative tools to permit creation of DKIM key records.

A validator needs to add code to the appropriate agent and then feed the result into the portion of their system needing it, such as a filtering engine.

The mere existence of a valid signature does not imply that the mail is acceptable, such as for delivery. Acceptability requires an assessment phase. Hence the result of signature validation must be fed into a vetting mechanism that is part of the validator's filter.

 

• When should I consider deploying DKIM?

DKIM is ready for use today. There already are multiple implementations, including some that are open source, and it is in production operation.

NOTE:

DKIM can provide a significant benefit to each site that implements it, independent of implementation by any other site. When a site begins signing all mail, it can immediately detect any incoming email that purports to have originated from that site, but is not signed and is therefore not valid. That can effectively eliminate substantial amounts of spam and phishing that is based on the addresses of users at the site.

Please see the Deployment page.

 

• When will the Service Providers start using DKIM?

Some already are. DKIM permits incremental adoption and use, so that benefit can accrue quickly; they increase as more sites start using it.

• What is a technical summary of the way DKIM works?

DKIM defines an authentication mechanism for email, using:

• A domain name identifier
• Public-key cryptography
• A DNS-based public key publishing service.

An agent in the message transit path can sign the message content and selected header fields. The signature information is placed into a field of the RFC2822 message header.

Validation of the signature, by a later agent in the path, demonstrates that the signing identity took responsibility for the message.

There also are mechanisms for listing formal assertions about the signature or the message. This publicly registers the signing organization's message signing practices.

• What are DKIM's technical goals?

• Low implementation and operations costs (avoid large PKI, new Internet services)
• No trusted third parties required (e.g., key servers)
• No client or recipient User Agent upgrades required
• No changes for end users required
• Validate message itself (not just its path)
• Allow delegation of signing authority (e.g., for outsourcing)
• Extensible (key service, hash, public key)
• Structure usable for per-user sign-in

• What is a DKIM "selector"?

A selector is added to the domain name, used to find DKIM public key information. It is specified as an attribute for a DKIM signature, and is recorded in the DKIM-Signature header field.

Validation uses the selector as an additional name component, to give differential DNS query names. There are different DKIM DNS records associated with different selectors, under the same domain name.

For example:

jun2005.eng._domainkey.example.com

Hence, selectors are used to permit multiple keys under the same organization's domain name. This can be used to give separate signatory controls among departments, date ranges, or third parties acting on behalf of the domain name owner..

• How is a DKIM signature recorded in a message

A DKIM signature is recorded as an RFC2822 header field for the signed message.

For example:

DKIM-Signature a=rsa-sha1; q=dns;
     d=example.com;
     i=user@eng.example.com;
     s=jun2005.eng; c=relaxed/simple;
     t=1117574938; x=1118006938;
     h=from:to:subject:date;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb
     av+yuU4zGeeruD00lszZVoG4ZHRNiYzR

• Since uses technology that is similar to S/MIME and OpenPGP, to sign a message, why not one of these earlier methods? They already are IETF standards.

DKIM is based on domain names, rather than complete email addresses. Hence, signing is controlled by the administrator of the domain name, rather than by individual email users.

DKIM uses DNS-based self-certified keys. Because the scope of DKIM is limited, it does not need generalized, powerful and long-term certificates, issued by separate authorities.

S/MIME and OpenPGP are intended for longer-term, personal protection and therefore use costlier mechanisms and per-user identification, with the requirement that key and certification information, needed for a given message, be available essentially forever.

Also they require modification of the message body, to provide their packaging as MIME body-part types. DKIM does not modify the body. Rather it places its parametric information into header fields that are typically not shown to the recipient. Therefore DKIM's can be entirely invisible to recipients.

Using domain names, rather than email addresses, provides particular advantages, as discussed in Crypto and Spam.

• What are the differences between DomainKeys (DK) and DKIM

DKIM has enhanced the DK DNS key record, to permit the addition of several parameters.

DKIM permits the signing identity to be different from the identities used for the author or the initial posting agent. This is essential, for example, to enable support of signing by authorized third-parties, and to permit signatures by email providers who are otherwise independent of the domain name of the message author.

DKIM permits restricting the use of a signature key to particular types of services, such as only for email. This is helpful when delegating signing authority, such as to a particular department or to a third-party outsourcing service.

DKIM self-signs the DKIM-Signature header field, to protect against its being modified.

In order to survive the vagaries of different email transfer systems, mechanisms like DKIM must evaluate the message data in some canonical form, such as treating a string of spaces as tabs as if they were a single space. DKIM has added the "relaxed" canonicalization in place of "nofws".

DomainKeys has a parameter that allows restricting use of a signature key to a specific user mailbox value, such as mailbox@example.com. DKIM enhances this to permit specifying a portion of the mailbox string as a wildcard, such as"mailbox+*". This is useful to handle the unofficial practice of "sub-addressing" such as for distinguishing among a user's different categories of email exchange.

With DKIM the signer MUST explicitly list the headers that are signed. This is an improvement because it requires the signer to use the more conservative (likely to verify correctly) mechanism and makes it considerably more robust against the handling of intermediary MTAs.

DKIM supports signature timeouts. Hence a signature can explicitly declare how long the DNS must be able to satisfy queries about the signature key.

DKIM includes language to make it clear which particular header field is signed, if there is more than one header field of a given name in the message.

DKIM allows body length limits, to permit signatures, to survive transit through some intermediaries, such as some mailing list agents that add text to the end of the message.

• More DKIM/DomainKeys differences:
  • DKIM uses a different RFC2822 header field for storing the signature, in order to distinguish it from DK.
  • DKIM has split header and body canonicalization.
  • DKIM allows multi-character tag names.
  • DKIM does not support the DomainKey-X509: header.
  • DKIM has divided the signing policy into a separate document, which will probably differ from that of DomainKeys.
  • DKIM allows some values that were scalars in DomainKeys to be colon-separated arrays. For example, the list of query methods used to find a key and the "t=" tags (originally testing, now flags).
  • DKIM permits copying the original version of headers fields and their values, to aid in diagnosing signatures that do not survive transit.
  • DKIM has the ability to limit keys to hash algorithms specified in a list, in the DNS record