We previously covered SPF record which is one way to increase delivery rates and in some cases prevent abuse (remember spf protection can be easily bypassed). However, SPF alone is not good enough protection which is why we would be introducing DKIM. DKIM (DomainKeys Identified Mail) allows senders to associate a domain name with an email message, thus vouching for its authenticity. This is done by “signing” the email with a digital signature, a field that is added to the message’s header.
DKIM is pretty complicated as the authentication happens via cryptographic authentication but we will highlight the basic steps in high level needed so an organisation can understand how DKIM record work.
Step 1: Identifying what message elements to sign with DKIM
It is up to the sender to decide which fields they want to sign (it can be either the whole message including body) or just few fields from the header. However, the elements selected to be signed must remain unchanged in transit or the DKIM signature will fail authentication.
Let’s look at the following example to better understand how DKIM would work in each situation.
- DKIM is signing the whole message (header and body).
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, since body was included in the DKIM signing process, the DKIM authentication will fail for the forwarded email.
- DKIM is signing specific fields from the email header
Taking the same example, if the email was forwarded and we have decided to sign only the “From” field, then the DKIM authentication would pass
Step 2: The encryption process
I won’t go through the maths as they can be bit boring but it comes down to this
Whatever fields you decide to sign, your server (the one sending the email) would create a hash string that represents the specific fields (example of hash : b23b5185a5223ba7a738a2c87900aea0) . Your server would then encrypt that hash with your server private key (Your server only must have access to your private key).
Step 3: Validating DKIM key
One the email has been received, the DKIM validation process starts. The receiving mail server will run a DNS query (step 3 below on how hosting providers can push DKIM records) to find the public key for that domain combination and because of how private/public key works, your mail server would be able to decrypt the DKIM signature back to the original hash string and therefore confirm that the email was not altered in transit (the specific fields signed with DKIM that is!).
Let’s now see how can organisations generate DKIM records. The process is outlined below but depending on the email provider you use, you might have to skip some steps
- Create a selector, which is a simple, user-defined text string. You will associate the selector with a public key in a later step.
- Generate a public-private key pair by using a tool such as ssh-keygen on Linux or PuTTYgen on Windows.
- Publish the selector and public key by creating a DKIM TXT record.
- Attach the token to each outgoing email.
So this is in a nutshell why DKIM should be used:
- The DKIM domain really “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)
Unfortunately, DKIM does nothing to prevent the spoofing of the visible “header from” domain. For this reason we will can further enhance the email protection with the use of DMARC
If you have any questions of need help setting up DKIM record please leave a comment below