The need for email validated identification arises because forged addresses and content are otherwise easily created—and widely used in spam, phishing and other email-based fraud.
[5] DKIM provides the ability to sign a message, and allows the signer (author organization) to communicate which email it considers legitimate.
Signing modules insert one or more DKIM-Signature: header fields, possibly on behalf of the author organization or the originating service provider.
The semantics of the AUID are intentionally left undefined, and may be used by the signing domain to establish a more fine-grained sphere of responsibility.
[2] A receiving SMTP server wanting to verify uses the domain name and the selector to perform a DNS lookup.
This gives the TXT resource record to be looked up as: brisbane._domainkey.example.net Note that the selector and the domain name can be UTF-8 in internationalized email.
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.
DMARC provides the ability for an organisation to publish a policy that specifies which mechanism (DKIM, SPF, or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures—and a reporting mechanism for actions performed under those policies.
There are some incentives for mail senders to sign outgoing e-mail: 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.
DKIM used to have an optional feature called ADSP that lets authors that sign all their mail self-identify, but it was demoted to historic status in November 2013.
[17] For example, using DMARC, eBay and PayPal both publish policies that all of their mail is authenticated, and requesting that any receiving system, such as Gmail, should reject any that is not.
[18] Because it is implemented using DNS records and an added RFC 5322 header field, DKIM is compatible with the existing e-mail infrastructure.
[citation needed] DKIM's non-repudiation feature prevents senders (such as spammers) from credibly denying having sent an email.
It has proven useful to news media sources such as WikiLeaks, which has been able to leverage DKIM body signatures to prove that leaked emails were genuine and not tampered with.
However, in order to definitely disable non-repudiation, expired secret keys can be published, thereby allowing everyone to produce fake signatures, thus voiding the significance of original ones.
Effectiveness of the scenario can hardly be limited by filtering outgoing mail, as that implies the ability to detect if a message might potentially be useful to spammers.
[28] 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,[29] enjoy the robustness that end-to-end integrity requires.
The OpenDKIM Project organized a data collection involving 21 mail servers and millions of messages.
Without specific precaution implemented by the sender, the footer addition operated by most mailing lists and many central antivirus solutions will break the DKIM signature.
For yet another workaround, it was proposed that forwarders verify the signature, modify the email, and then re-sign the message with a Sender: header.
Wired stated that Harris reported, and Google confirmed, that they began using new longer keys soon after his disclosure.
[35] DKIM resulted in 2004 from merging two similar efforts, "enhanced DomainKeys" from Yahoo and "Identified Internet Mail" from Cisco.
[48][irrelevant citation] In 2017, another working group was launched, DKIM Crypto Update (dcrup), with the specific restriction to review signing techniques.
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.
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.