DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is a method for associating a domain name to an email message, thereby allowing a person, role, or organization to claim some responsibility for the message. The association is set up by means of a digital signature which can be validated by recipients. Responsibility is claimed by a signer —independently of the message's actual authors or recipients— by adding a DKIM-Signature: field to the message's header. The verifier recovers the signer's public key using the DNS, and then verifies that the signature matches the actual message's content.

A DKIM signature can cover other fields of a message's header, such as the From: and Subject: fields, and the message body (or its initial part). The DKIM-Signature field itself is always implicitly covered, and, besides the signature proper, contains other data identified by tags, such as the domain name, the list of covered fields, the signing algorithm, and the method by which text snippets are simplified for signing purposes (canonicalization). Thus, the strength of a DKIM-Signature can be tuned so as to allow those message modifications that are considered "normal". Note that DKIM is not designed to provide end-to-end integrity.^[1]

Prominent email service providers implementing DKIM include Yahoo, Gmail, and FastMail.FM. Any mail from these organizations should carry a DKIM signature.^[2][3][4][5]

DKIM, as stated on the DKIM homepage, is the result of merging DomainKeys and Identified Internet Mail. This merged specification has been the basis for a series of IETF standards-track specifications and support documents.

Overview

Both modules, signing and verifying, are usually part of a mail transfer agent (MTA). The signing organization can be a direct handler of the message, such as the author, the originating sending site or an intermediary along the transit path; or an indirect handler, such as an independent service that is providing assistance to a direct handler. In most cases, the signing module acts on behalf of the author organization or the originating service provider, by inserting a DKIM-Signature: header field. The verifying module typically acts on behalf of the receiver organization.

The need for this type of validated identification arose because spam often has forged addresses and content. For example, a spam message may claim in its "From:" header field to be from [e-mail], when it is not from that address, and the spammer's goal is to convince the recipient to accept and to read the email. Because the email is not from the example.com domain, complaining there is not useful. It also becomes difficult for recipients to establish whether to trust or distrust any particular domain, and system administrators may have to deal with complaints about spam that appears to have originated from their systems, but did not.

DKIM is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 5322 message —the transported mail's header and body— not the SMTP envelope defined in RFC 5321. Hence the DKIM signature survives basic relaying across multiple MTAs.

DKIM allows the signer to distinguish its legitimate mail stream. It does not directly prevent or disclose abusive behavior. This ability to distinguish legitimate mail from potentially forged mail has benefits for recipients of e-mail as well as senders, and "DKIM awareness" is programmed into some e-mail software.

How it works

The "DKIM-Signature" header field consists of a list of "tag=value" parts. Tags have very short names, usually one or two letters. The most relevant ones are b for the actual digital signature of the contents (headers and body) of the mail message, bh for the body hash, d for the signing domain, and s for the selector. The default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64.

The receiving SMTP server uses the domain name and the selector to perform a DNS lookup. For example, given the signature

  DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
     c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938;
     h=from:to:subject:date:keywords:keywords;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

 a verifier queries the TXT resource record type of brisbane._domainkey.example.net. There are no CAs nor revocation lists involved in DKIM key management, and the selector is a straightforward method to allow signers to add and remove keys whenever they wish —long lasting signatures for archival purposes are outside DKIM's scope. Some more tags are visible in the example: v is the version, a is the signing algorithm, c is the canonicalization algorithm(s) for header and body, q is the default query method, l is the length of the canonicalized part of the body that has been signed, t is the signature timestamp, x is its expire time, and h is the list of signed header fields, repeated for fields that occur multiple times. Note that the DKIM-Signature header field itself is always implicitly included in h.

The data returned from the query is also a list. It includes the domain's public key, along with other key usage tokens and flags. The receiver can use this to then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail message (headers and body) that was received. If the two values match, this cryptographically proves that the mail was signed by the indicated domain and has not been tampered with in transit.

Signature verification failure does not force rejection of the message. Instead, the precise reasons why the authenticity of the message could not be proven should be made available to downstream and upstream processes. Methods for doing so may include sending back an FBL message, or adding an Authentication-Results header to the message as described in RFC 5451.

Development

The original DomainKeys was designed by Mark Delany of Yahoo! and enhanced through comments from many others since 2004. It is specified in Historic RFC 4870, obsoleted by Standards Track RFC 4871, DomainKeys Identified Mail (DKIM) Signatures; both published in May 2007. A number of clarifications and conceptualizations were collected thereafter, and specified in RFC 5672, August 2009, in the form of corrections to the existing specification. In September 2011, RFC 6376 merged and updated the latter two documents, while preserving the substance of the DKIM protocol. Key compatibility with the earlier DomainKeys is also possible.

DKIM was initially produced by an informal industry consortium and was then submitted for enhancement and standardization by the IETF DKIM Working Group, chaired by Barry Leiba and Stephen Farrell, with Eric Allman of sendmail, Jon Callas of PGP Corporation, Mark Delany and Miles Libbey of Yahoo!, and Jim Fenton and Michael Thomas of Cisco Systems attributed as primary authors.

Source code development is led by The OpenDKIM Project, following the most recent protocol additions, and licensing under the New BSD License.

Patent encumbrance

DomainKeys is covered by U.S. Patent 6,986,049 assigned to Yahoo! Inc. For the purpose of the DKIM IETF Working Group, Yahoo! released the now obsolete DK library under a dual license scheme: the DomainKeys Patent License Agreement v1.2, an unsigned version of which can still be found,^[6] and GNU General Public License v2.0 (and no other version).^[7][8]

Advantages

The primary advantage of this system for e-mail recipients is it allows the signing domain to reliably identify a stream of legitimate email, thereby allowing domain-based blacklists and whitelists to be more effective.^[9] This is also likely to make some kinds of phishing attacks easier to detect.

There are some incentives for mail senders to sign outgoing e-mail:

• It allows a great reduction in abuse desk work for DKIM-enabled domains if e-mail receivers use the DKIM system to identify forged e-mail messages claiming to be from that domain.
• The domain owner can then focus its abuse team energies on its own users who actually are making inappropriate use of that domain.

Use with spam filtering

DKIM is a method of labeling a message, and it does not itself filter or identify spam. However, widespread use of DKIM can prevent spammers from forging the source address of their messages, a technique they commonly employ today. If spammers are forced to show a correct source domain, other filtering techniques can work more effectively. In particular, the source domain can feed into a reputation system to better identify spam. Conversely, DKIM can make it easier to identify mail that is known not to be spam and need not be filtered. If a receiving system has a whitelist of known good sending domains, either locally maintained or from third party certifiers, it can skip the filtering on signed mail from those domains, and perhaps filter the remaining mail more aggressively.^[9]

Anti-Phishing

DKIM can be useful as an anti-phishing technology. Mailers in heavily phished domains can sign their mail to show that it is genuine. Recipients can take the absence of a valid signature on mail from those domains to be an indication that the mail is probably forged. The best way to determine the set of domains that merit this degree of scrutiny remains an open question; DKIM will likely^[update] have an optional feature called ADSP that lets authors that sign all their mail self-identify, but the effectiveness of this approach remains to be tested.

Working with eBay and PayPal, Google has effectively utilized DKIM in GMail in such a way that any e-mail that claims to be coming from ebay.com or paypal.com will not be accepted at all if they cannot be verified successfully with DKIM. Such messages won't even appear in the Spam folder. ^[10]

Compatibility

Because it is implemented using DNS records and an added RFC 5322 header field, DKIM is compatible with the existing e-mail infrastructure. In particular, it is transparent to existing e-mail systems that lack DKIM support.

This design approach also is compatible with other, related services, such as the S/MIME and OpenPGP content-protection standards. DKIM is orthogonal to, and compatible with, the DNSSEC standard and with SPF.

Protocol overhead

DKIM requires cryptographic checksums to be generated for each message sent through a mail server, which results in computational overhead not otherwise required for e-mail delivery. This additional computational overhead is a hallmark of digital postmarks, making sending bulk spam more (computationally) expensive.^[11]

Weaknesses

DKIM signatures do not encompass the message envelope, which holds the return-path and message recipients. Since DKIM does not attempt to protect against mis-addressing, this does not affect its utility. A concern for any cryptographic solution would be message replay abuse, which bypasses techniques that currently limit the level of abuse from larger domains. Replay can be inferred by using per-message public keys, tracking the DNS queries for those keys and filtering out the high number of queries due to e-mail being sent to large mailing lists or malicious queries by bad actors. For a comparison of different methods also addressing this problem see e-mail authentication.

Arbitrary forwarding

As mentioned above, authentication is not the same as abuse prevention: DKIM doesn't prevent a spammer from composing an ad at a reputable domain so as to obtain a signed copy of the message. Using an l tag in a signature makes doctoring such messages even easier. The signed copy can then be forwarded to millions of recipients, e.g. through a botnet, without control. The email provider who signed the message can block the offending user, but cannot stop the diffusion of already signed messages. The validity of signatures in such messages can be limited by always including an expiration time tag in signatures, or by revoking a public key periodically or upon a notification of an incident. Effectiveness of the scenario can be limited by filtering outgoing mail, ensuring that messages potentially useful to spammers are not being signed, or just not sent.

Content modification

DKIM currently features two canonicalization algorithms, simple and relaxed, neither of which is MIME-aware.^[12] Mail servers can legitimately convert to a different character set, and often document this with X-MIME-Autoconverted header fields. In addition, servers in certain circumstances have to rewrite the MIME structure, thereby altering the preamble, the epilogue, and entity boundaries, any of which breaks DKIM signatures. Only plain text messages written in us-ascii, provided that MIME header fields are not signed,^[13] enjoy the robustness that end-to-end integrity requires.

These problems are exacerbated when filtering or relaying software adds actual changes to a message. Although legitimate, the footer addition operated by most mailing lists and many central antivirus solutions, formally, are exactly the kind of message tampering that DKIM has been designed to guard against. The solution is to whitelist known forwarders, e.g. by SPF. Alternatively, a forwarder can verify the signature, modify the e-mail, and resign the message with a Sender: header. However, it should be noted that this solution has its risk with forwarded 3rd party signed messages received at SMTP receivers supporting the RFC 5617 ADSP protocol. Thus, in practice, the receiving server still has to whitelist known message streams, i.e. by DKIM.

Some suggest that these limitations could be addressed by combining DKIM with SPF, because SPF (which breaks when messages are forwarded) is immune to modifications of the e-mail data, and mailing lists typically use their own SMTP error address, also known as Return-Path. In short, SPF works without problems where DKIM might run into difficulties, and vice versa.

Protocol overhead

DKIM requires cryptographic checksums to be generated for each message sent through a mail server, which results in computational overhead not otherwise required for e-mail delivery.

See also

• E-mail authentication
• DomainKeys
• Sender Policy Framework (SPF)
• Author Domain Signing Practices (ADSP)
• S/MIME
• OpenPGP
• Vouch by Reference

References

1. ^ D. Crocker; T. Hansen; M. Kucherawy (21 September 2011). "DomainKeys Identified Mail (DKIM) Signatures". Draft Standard. IETF. http://tools.ietf.org/html/rfc6376#section-1.5. "Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message." 
2. ^ Post on the Yahoo! Corporate Blog by Mark Delany, credited as Chief Architect, inventor of DomainKeys
3. ^ Post on the Gmail Blog advertising support for DKIM in Gmail while receiving
4. ^ Gmail help entry mentioning DKIM support when sending
5. ^ FastMail blog entry: all outbound email now being DKIM signed
6. ^ "Yahoo! DomainKeys Patent License Agreement v1.1". SourceForge. 2006. http://domainkeys.sourceforge.net/license/patentlicense1-2.html. Retrieved 2010-05-30. "Yahoo! DomainKeys Patent License Agreement v1.2" 
7. ^ John R. Levine (Mon Jan 25 08:51:48 PST 2010). "IPR disclosures, was Collecting re-chartering questions". ietf-dkim mailing list. Mutual Internet Practices Association. http://mipassoc.org/pipermail/ietf-dkim/2010q1/012939.html. Retrieved 2010-05-30. "The reference to the GPL looks to me like it only covers the old Sourceforge DK library, which I don't think anyone uses any more. The patent, which is what's important, is covered by a separate license that Yahoo wrote." 
8. ^ Andy Chen (26 September 2011). "Yahoo! Inc.'s Statement about IPR related to RFC 6376". IPR disclosure. IETF. https://datatracker.ietf.org/ipr/1615/. Retrieved 3 October 2011. 
9. ^ ^{a b} Falk, J.D. (2009-03-17). "Searching for Truth in DKIM". CircleID. http://www.circleid.com/posts/20090317_searching_for_truth_in_dkim_part_3/. 
10. ^ http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html
11. ^ http://blogs.office.com/b/microsoft-outlook/archive/2007/07/05/postmarking-helping-the-fight-against-spam.aspx
12. ^ Ned Freed (with agreement by John Klensin) (Fri, 05 Mar 2010 09:49:35 -0500). "secdir review of draft-ietf-yam-rfc1652bis-03". YAM mailing list. IETF. http://www.ietf.org/mail-archive/web/yam/current/msg00381.html. Retrieved 2010-05-30. "DKIM WG opted for canonical form simplicity over a canonical form that's robust in the face of encoding changes. It was their engineering choice to make and they made it." 
13. ^ RFC 2045 allows a parameter value to be either a token or a quoted-string, e.g. in format="flowed" the quotes can be legally removed, which breaks DKIM signatures.

External links

• DomainKeys Identified Mail (DKIM)
• IETF DKIM working group (started 2006, concluded 2011)

- DKIM Specifications

• RFC 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
• RFC 4871 DomainKeys Identified Mail (DKIM) Signatures Proposed Standard
• RFC 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
• RFC 5585 DomainKeys Identified Mail (DKIM) Service Overview
• RFC 5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
• RFC 5863 DKIM Development, Deployment, and Operations
• RFC 6376 DomainKeys Identified Mail (DKIM) Signatures Draft Standard
• RFC 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists

- DKIM Information and tools

• Internet Messaging Leaders Work Together to Fight Email Fraud
• DKIM Software and Services Deployment Reports
• DKIM-Reputation Project Open reputation data on sender domains
• DKIM implementation for quick integration with javamail (BSD license)
• DKIM installation for Exim Tutorial for installing DKIM for outbound messages using Exim
• DKIM Signature and verification using DKIMproxy DKIM protocol description and integration with Postfix on Debian
• Blog entry describing DKIM
• DKIM signer/verifier drop-in replacement for qmail-queue
• Domain Keys Identified Mail (DKIM) DNS Record Generator
• OpenDKIM Open source DKIM library and signing/verifying filter for Sendmail and Postfix
• Crocker, Dave (March 2008) (PDF). Trust in Email Begins With Authentication. Messaging Anti-Abuse Working Group. http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Authentication_Paper.pdf