DomainKeys Identified Mail (DKIM) is a standard that allows the owner of an Internet domain name to sign emails that originate from it, so that destination servers can verify whether an email actually comes from that domain, and whether its key headers have been modified.
In DKIM, the owner of a domain name creates a couple of private and public cryptographic keys; the private key is deployed on the outgoing mail servers for the domain, while the matching public key is published in a special DNS record for that domain name. In this way, when receiving a DKIM-signed message, any email server can retrieve the public key from the DNS and verify the signature.
To sign a message, the originating mail server will compute a hash of the body of the message and of a customizable subset of its headers (From:, Subject: etc.), and then use the private key to sign these hashes. The result will be stored into a special DKIM-Signature: header that will be added to the message as it leaves the server.
On the other hand, DKIM does not sign the entire message including all of its headers, because some headers will necessarily change or be added as the message travels through the Internet. The list of the headers that were actually signed is included in the DKIM-Signature: header, and must include at least From:. As there is no requirement that the signing domain is the same of the sender’s address, email applications that modify the body and/or the signed headers of the message, such as mailing list managers, can simply remove any originating DKIM signature and sign the message again on their own (but if they do not do this, DKIM verification will fail).
Also, there is no requirement that the signing domain is the same of the originating server’s hostname; the only required match is between any domain name listed as signer in the DKIM-Signature: header, and the domain name under which the public key is retrieved. This allows to locate or outsource the signing operation with maximum flexibility.
Originating domains can use multiple private keys; this can be done because of multiple outgoing servers each using a different key, or because of an ongoing key rollover, or so on. For this reason, the domain owner can publish in the DNS multiple keys, each identified by a string named selector. The selector of the key is also included in the DKIM-Signature: field, so that the receiving server can pick the correct key for verification; the receiving server simply asks for the DNS TXT record corresponding to “<selector>._domainkey.<signingdomain>”.
Upon reception of a DKIM-signed message that has a valid signature, the receiving server acquires a limited but important certainty: the signing domain is responsible for that message. However, DKIM does not provide any policy on what should be done with the verified messages, both in case of success or failure. Usually, recipents mark as dubious or reject any message with a broken DKIM signature, and whitelist validly signed messages unless the verified source is unreputable. DMARC is a complementary standard that allows senders to suggest policies for those who receive their messages.
Though using cryptography, DKIM does not actually encrypt the message and so it is useless against email interception; it only helps against spamming and phishing.
You will find more information about DKIM on the DKIM.org website. Differently from SPF and DMARC, DKIM actually requires software to be written and installed on email servers; a free software implementation can be found at OpenDKIM.
