DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is a method for email authentication that allows an organization to take responsibility for a message in a way that can be validated by a recipient. The 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. The need for this type of authentication originally arose because spam often has forged content. For example, a spam message may claim in its "From:" header field to be from sender@example.com, 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 uses public-key cryptography to allow the signer to electronically sign legitimate emails in a way that can be verified by recipients. Prominent email service providers implementing DKIM include Yahoo, Gmail, and FastMail. Any mail from these organizations should carry a DKIM signature.

DKIM also guards against tampering with mail, offering end-to-end integrity from a signing module to a verifying module, such as a mail transfer agent (MTA). In most cases the signing module acts on behalf of the author organization by inserting a DKIM-Signature header field, and the verifying module on behalf of the receiver organization, validating the signature by retrieving a signer's public key through the DNS.

DKIM, as stated by the DKIM Organization's homepage, is the result of merging DomainKeys and Identified Internet Mail. This merged specification has been the basis for an IETF Working Group which has produced a series of standards-track specifications and support documents.

Overview

DKIM is a method of e-mail authentication. Unlike some other methods, it offers end-to-end integrity from a signing module to a verifying module, such as a Mail Transfer Agent (MTA). In most cases the signing module acts on behalf of the sender organization and the verifying module on behalf of the receiver organization. DomainKeys is specified in Historic RFC 4870, which is obsoleted by Standards Track RFC 4871, DomainKeys Identified Mail (DKIM) Signatures.

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.

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

DKIM adds a header field named "DKIM-Signature" that contains a digital signature of the contents (headers and body) of the mail message. 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 name of the domain from which the mail originated, the string "_domainkey", and a selector from the DKIM-Signature field to perform a DNS lookup. The returned data includes the domain's public key. 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

DomainKeys was designed by Mark Delany of Yahoo! and enhanced through comments from many others.

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.

DomainKeys is covered by U.S. Patent 6,986,049 assigned to Yahoo!, which has released DomainKeys under a dual license scheme: the traditional corporate-oriented royalty-free, nonexclusive, relicensable patent license designed to be friendly to open source and free software implementations, and under GPL 2.0 for the purpose of the DKIM IETF Working Group.

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. 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 an authentication technology, 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.

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 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 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.

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.

Weaknesses

DKIM signatures do not encompass the message envelope, which holds the return-path and message recipients. 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. 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.

Content modification in-transit

One of the problems with DKIM is that if the message is significantly modified en route by a forwarding mechanism such as a list server, the signature may no longer be valid, and if the domain specifies that all e-mail is signed, the message may be rejected. Many central antivirus solutions add a footer that the email has been scanned and the date of the virus signature files used in the scan. Some free email servers add advertisements at the bottom of the emails. The solution is to whitelist e-mail from known forwarders, or for the forwarder to 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.

Many domains, however, say that only some of their e-mail is signed, and so a missing or broken signature can not always be used to reject e-mail. The solution here is to sign all your e-mail. If the only modifications en-route involve the addition or modification of header fields, the signature should remain valid; also the mechanism includes features that allow certain limited modifications to be made to headers and the message body without invalidating the signature.

Some suggest that this limitation 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.

Mailing lists that add or change content also effectively invalidate DKIM signatures. Yahoo! suggested that the mailing list should re-sign the message itself under these circumstances, thus in effect taking responsibility for the message.

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

External links

• Domain Keys Identified Mail (DKIM)
• IETF DKIM working group (started 2006)

- DKIM Specifications

• RFC 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
• RFC 4871 DomainKeys Identified Mail (DKIM) Signatures
• RFC 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
• RFC 5585 DomainKeys Identified Mail (DKIM) Service Overview

- DKIM Information and tools

• Internet Messaging Leaders Work Together to Fight Email Fraud
• DKIM Software and Services Deployment Reports
• DKIM-Connector Tool to simplify DKIM deployment
• DKIM implementation for quick integration with javamail (BSD license)
• DKIM installation for Exim Tutorial for installing DKIM for outbound messages using Exim
• DomainKeys on cPanel Implementing DomainKeys on a cPanel powered server
• Domain Keys Identified Mail (DKIM)
• DKIM signer/verifier drop-in replacement for qmail-queue
• Domain Keys Identified Mail (DKIM) DNS Record Generator
• OpenDKIM (open source DKIM 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