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 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 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.
Read more about this topic: Dkim