omainKeys is an e-mail authentication system (developed at Yahoo!) designed to verify the DNS domain of an E-mail sender and the message integrity. The DomainKeys specification has adopted aspects of Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM). This merged specification is the basis for an IETF Working Group which plans to guide the specification toward becoming an IETF standard.
DomainKeys is a method of e-mail authentication. Unlike some other methods, it offers almost end-to-end integrity from a signing to a verifying Mail Transfer Agent (MTA). In most cases the signing MTA acts on behalf of the sender, and the verifying MTA on behalf of the receiver.
DomainKeys is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 2822 message — i.e., the transported mail data, header and body — not the SMTP envelope defined in RFC 2821.
Note that DomainKeys does not prevent abusive behavior; rather, it allows abuse to be tracked and detected more easily. This ability to prevent some forgery also has benefits for recipients of E-mails as well as senders, and “DomainKey awareness” is programmed into some E-mail software.
Since 2004, Yahoo! has signed all of its outgoing E-mail with DomainKeys and is verifying all incoming mail. As of 2005, Yahoo! reports that the number of DomainKeys-verified e-mail they receive exceeds 300 million messages per day.
Google also uses DomainKeys to sign emails sent from users of its Gmail service, actually going live with it about a month before Yahoo! did. The ISP EarthLink also uses DomainKeys.
From Wikipedia, the free encyclopedia:
DomainKeys Identified Mail is a method for E-mail authentication. It offers almost end-to-end integrity from a signing to a verifying Mail transfer agent (MTA). In most cases the signing MTA acts on behalf of the sender by inserting a DKIM-Signature header, and the verifying MTA on behalf of the receiver, validating the signature by retrieving a sender’s public key through the DNS.
The DomainKeys specification has adopted aspects of Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM). This merged specification is the basis for an IETF Working Group which has guided the specification towards becoming an IETF Proposed Standard.

How it works
DomainKeys adds a header named “DomainKey-Signature” that contains a digital signature of the contents of the mail message. The default parameters for the authentication mechanism are to use SHA-1 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64.
The receiving SMTP server then uses the name of the domain from which the mail originated, the string _domainkey, and a selector from the header to perform a DNS lookup. The returned data includes that domain’s public key. The receiver can then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail body that was received, from the point immediately following the “DomainKey-Signature:” header. If the two values match, this cryptographically proves that the mail did in fact originate at the purported domain, and has not been tampered with in transit.
Development
DomainKeys was designed by Mark Delany of Yahoo!. Many other people including Russ Nelson of qmail, Eric Allman of sendmail, and John R. Levine of the ASRG provided comments and wrote prototype implementations.
DomainKeys is covered by U.S. Patent 6,986,049 assigned to Yahoo!. Yahoo! released DomainKeys under a dual license scheme: the traditional corporate oriented royalty-free, nonexclusive, relicensable patent license which is 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
There are three primary advantages of this system for email recipients:
* It allows the originating domain of an E-mail to be positively identified, allowing domain-based blacklists and whitelists to be more effective. This is also likely to make phishing attacks easier to detect.
* It allows forged E-mails to be discarded on sight, either by end-user E-mail software (mail user agents), or by ISPs’ mail transfer agents.
* It allows abusive domain owners to be tracked more easily.
There are some incentives for mail senders to authenticate outgoing email:
* It allows a great reduction in abuse desk work for DomainKeys-enabled domains if E-mail receivers use the DomainKeys system to automatically drop forged E-mails claiming to be from that domain.
* The domain owner can then focus their abuse team energies on their own users who actually are abusing their use of that domain.
Use with spam filtering
Since DomainKeys is an authentication technology, it is not directly useful in spam filtering. However, widespread use of DomainKeys 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 address, then other filtering techniques (such as collaborative databases) can be used to detect spam more reliably. Conversely, DomainKeys 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.
DK 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; DK’s successor DKIM will probably have an optional feature called SSP (Sender Signing Policy) that lets senders that sign all their mail self-identify, but the effectiveness of this approach remains untested.
Compatibility
Because it is implemented using optional RFC 2822 headers and DNS records, DomainKeys is backwards-compatible with the existing E-mail infrastructure. In particular, it is transparent to existing E-mail systems with no DomainKeys support.
DomainKeys has also been designed to be compatible with other proposed extensions to the E-mail system, in particular to be compatible with SPF, the S/MIME E-mail standard and DNSSEC. It is also compatible with the OpenPGP standard.
Weaknesses
DomainKeys or 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 email 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.
Content modification in-transit
One of the problems with DomainKeys is that if the message is significantly modified en route by a forwarding mechanism such as a list server, then the signature may no longer be valid and, if the domain specifies that all email is signed, the message may be rejected. (The solution is to whitelist email from known forwarders, or for the forwarder to verify the signature, modify the email, and resign the message with a Sender: header). Many domains, however, say that only some of their email is signed, and so a missing or broken signature can not always be used to reject email. (The solution is to sign all your email.) If the only modifications en-route involve the addition or modification of headers before the DomainKey-Signature: header, 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 DomainKeys with SPF, because SPF is immune to modifications of the e-mail data, and mailing lists typically use their own SMTP error address aka Return-Path. In short SPF works without problems where DomainKeys might run into difficulties, and vice versa.
Mailing Lists that add or change content also effectively invalidate DomainKeys 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
DomainKeys requires cryptographic checksums to be generated for each message sent through a mail server, which results in computational overhead not usually required for e-mail delivery. Until recently, this would have been a serious problem. However, as of 2006, both server and desktop computers have become fast enough to make this overhead negligible.