DomainKeys
DomainKeys is an e-mail authentication system 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 almostend-to-end integrity from a
signing to a
verifying Mail transfer agent (MTA). Inmost cases the signing MTA acts on behalf of the
sender, and the verifying MTA on behalf ofthe
receiver.DomainKeys is independent of
Simple Mail Transfer Protocol (SMTP) routingaspects in that it operates on the RFC 2822 message -- i.e., thetransported mail data, header and body -- not theSMTP 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 someE-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 thatthe 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.
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 assigned to Yahoo!. Yahoo! have 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.
Identified Internet Mail, on which
DKIM was also based, was proposed by
Jim Fenton and
Michael Thomas of
Cisco.
There are three primary advantages of this system for the domain owner:
* 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 other E-mail users to be able to verify DomainKey information:
* 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. DK can tell a recipient that a message that purports to be from
example.net is indeed from
example.net, but it cannot by itself say whether mail from
example.net is likely to be spam. The mere presence of a signature means nothing about a message's desirability, since spammers can and do sign mail just like anyone else.
DK can be useful as an anti-
phishing technology. Mailers in heavily phished domains can sign their mail to show that it isgenuine. 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.
DK can be indirectly useful in spam filtering by making 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.
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.
DomainKeys or DKIM signatures do not encompass themessage envelope, which holds the return-path andmessage 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 addressingalso 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. 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. 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 2004, computer processors are now fast enough that the cryptographic overhead represents only around 10% of the overall mail-handling load for a typical system.
*
E-mail authentication*
DomainKeys Identified Mail*
Sender Policy Framework (SPF)
*
Sender Signing Policy (SSP)
*
S/MIME*
OpenPGP*
Domain Keys Identified Mail (DKIM)*
IETF DKIM working group (started 2006)
*
Yahoo!'s description of DomainKeys* [https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=693 Yahoo!'s statement about IPR claimed in DKIM draft]
*
Yahoo!'s free software reference implementation of DomainKeys*
US Patent # 6,986,049*
SpamCop FAQ entry about bogus bounces discusses also DomainKeys
