DomainKeys Identified Mail (DKIM) is the most complicated email authentication protocol out there. Even if you do extensive research, it’s hard to find one place that describes how it all works.
That’s why we’re breaking it down in the second post of a three-part series that explains SPF, DKIM, and DMARC in plain English. (If you missed our first post on SPF, check it out here.)
What it is: DomainKeys Identified Mail (DKIM) is a protocol that allows an organization to take responsibility for transmitting a message in a way that can be verified by mailbox providers. This verification is made possible through cryptographic authentication.
How it works: DKIM is pretty complicated. There are a lot of steps. Below, we’ll break them down as simply as possible.
Step 1: Identifying what message elements to sign with DKIM
First, a sender decides which elements of the email they want to include in the signing process. They can decide to include the whole message (header and body) or just focus on one or more fields of the email header. The elements they decide to include in their DKIM signing process must remain unchanged in transit, or the DKIM signature will fail authentication.
The elements included in the DKIM signing process must remain unchanged in transit
For example, if an email is forwarded from Yahoo to Gmail, Yahoo may add a line of text at the top of the email (e.g. “forwarded by Yahoo mail”). At that point, the body of the email has been changed and, if the body was included in the DKIM signing process, the DKIM authentication will fail for the forwarded email.
However, if only an element of the header, such as the “from” field was included in the DKIM signature, and the message was forwarded from Yahoo to Gmail, the DKIM authentication would pass, since the part of the message that was changed was not signed by DKIM.
Step 2: The encryption process
So what does this signing process look like? Cryptography is at the center of it. The sender will configure their email platform to automatically create a hash of the parts of the email they want signed. The hashing process converts readable text into a unique textual string. Here’s what that looks like (using the MD5 hashing process):
From: Robert Holmes <[email protected]>
Subject: Testing
Maps to the following unique hash string:
3303baf8986f910720abcfa607d81f53
Before sending the email, that hash string is encrypted using a private key. The private key is assigned to a unique combination of domain and selector, allowing you to have multiple legitimate private keys for the same domain (which is important for email governance and security purposes). Only the sender has access to the private key.
After the encryption process is complete, the email is sent.
Step 3: Validating the DKIM signature with a public key
The email provider receiving the email sees that it has a DKIM signature, which reveals which “domain/selector” combination signed the encryption process. To validate the signature, the mailbox provider will run a DNS query to find the public key for that domain/selector combination.
This public key has the unique characteristic that it is the only match for the private key that signed the email, also known as a “keypair match.” The keypair match enables the email provider to decrypt the DKIM signature back to the original hash string.
The keypair match enables the email provider to decrypt the DKIM signature back to the original hash string.
The email provider then takes the elements of the email signed by DKIM and generates its own hash of these elements. Finally, the mailbox provider compares the hash it generated with the decrypted hash from the DKIM signature. If they match, we know that
- The DKIM domain really does “own” the email, otherwise the decryption process wouldn’t have worked in the first place
- The elements of the email signed by DKIM were not changed in transit (if they were changed, the hashes would not match)
Why it matters: Email providers who validate DKIM signatures can use information about the signer as part of a program to limit spam, spoofing, and phishing, although DKIM does not tell receivers to take any specific actions. Depending on the implementation, DKIM can also ensure that the message has not been modified or tampered with in transit.
The problem with DKIM is that because it’s more difficult to implement, fewer senders have adopted it. This spotty adoption means that the absence of a DKIM signature does not necessarily indicate the email is fraudulent. Therefore, DKIM alone is not a universally reliable way of authenticating the identity of a sender. In addition, the DKIM domain is not visible to the non-technical end user, and does nothing to prevent the spoofing of the visible “header from” domain.
The problem with DKIM is that because it’s more difficult to implement, fewer senders have adopted it.
DMARC, the latest and greatest advance in email authentication, addresses that problem, by guaranteeing that the domain visible to the end user is the same as the domains validated by the SPF and DKIM checks. In addition, it provides mailbox providers with clear instruction about which emails they should hold to the DKIM authentication standard and which they should not.
Next week, in our final post in the series, we’ll cover what DMARC is all about. In the meantime, now that you’re an expert, find out how to create a DKIM record here.