Mastering DKIM: Everything You Need to Know About Email Authentication

DKIM records are used in assessing the authenticity and integrity of an email message. Along with SPF and DMARC records, the DKIM record is an important part of email authentication, and by extension, email deliverability.

The DKIM (DomainKeys Identified Mail) protocol gives a way for receiving servers to verify the integrity of the message, that it's coming from the purported sender and it hasn't been modified from its original intended version.

Your DKIM records store your public signing key and email platform selectors to help receiving email servers verify that the mail has not been modified during transit.

DKIM Record Requirements
DKIM records do not replace the need for SPF and DMARC records. Instead, they all are important and work in conjunction with each out to ensure robust email authentication.

Each outgoing email message needs to have at least one valid DKIM signature or else DKIM authentication will fail and the receiving server may reject the message entirely.

For every sending platform you are actively using for email messages, you'll want at least one DKIM record configured for it. Unlike SPF records, multiple DKIM records are perfectly okay to exist on the same domain/subdomain, they just need unique selector values.

How DKIM Works
DKIM Process
The process for DKIM authentication is a bit complicated. Here's a graphic overview of the general steps involved in DKIM authentication:

DKIM Encryption/Decryption
The encryption-decryption for DKIM looks something like this:

1. Signing the Email (Sender Side): When the sender's server is preparing to send an email, it first creates a hash of the email (or certain parts of the email, defined in the DKIM header). This hash is a kind of 'digital fingerprint' of the email's content. The sender's server then 'encrypts' this hash using the server's private key. This creates the DKIM signature, which is attached to the email in the DKIM-Signature header.
   
   
2. Verifying the Signature (Recipient Side): When the recipient's server receives the email, it sees the DKIM-Signature header and retrieves the public key from the sender's domain DNS records. The recipient's server then 'decrypts' the DKIM signature using this public key. This doesn't produce the original email content (as would be the case with traditional encryption/decryption), but it does produce the original hash that the sender's server created.
   
   

In a traditional encryption scenario, you'd use the recipient's public key to encrypt the message, and the recipient would use their own private key to decrypt it. But in the case of DKIM signatures, the sender uses their own private key to 'sign' the message, and anyone can use the corresponding public key to verify that signature.

So in short:

f(Content hash + private key) = DKIM-signature hash
f(DKIM-signature hash + public key) = Content hash

This process ensures the integrity of the email (the content hasn't been tampered with during transit) and also the authenticity (the email actually originated from the claimed domain).

Remember, the purpose of DKIM is not to keep the email content confidential (that would be the role of encryption), but to verify its authenticity and integrity. The recipient generates its own hash of the received email content and compares it with the decrypted original hash. If they match, the email is verified as authentic and unaltered.

Luckily, as a typical email sender, you don't need to understand all of the inner workings of the process in order to make it work for you. You just need to make sure your DKIM record configuration and values are correct.

Creating a DKIM Record
Just like for the SPF record and DMARC record, the DKIM record is a TXT type record you add to your DNS records.

A typical DKIM record looks like this:

Let's break down the elements.

The host name of "google2._domainkey.us":

• The "google2." part is called the selector. This is chosen by each of your platforms and then conveyed over to you when setting up the DKIM records. The selector helps the receiving servers run the lookup on the records to find the DKIM record for that particular platform and thus locate the signing public key value.
  
  
• The "_domainkey" part is the accepted syntax for identifying the TXT record as a DKIM record.
  
  
• The ".us" suffix is referencing the subdomain of 'us' that we are putting this DKIM record on. If for example you are setting the DKIM record on this root domain, it would simply be 'google2._domainkey'.
  
  

Moving on to the record value:

• The "v=DKIM1" is the identifier that the TXT record is a DKIM record. The 'v' stands for version, which is also why there's a '1' in the value of DKIM1, indicative of version 1.
  
  
• "k=rsa" indicates the Key type, which is usually set to rsa. RSA is an encryption algorithm that's widely used in public-key cryptography (the method used in DKIM verification).
  
  
• The "p=MIIBIjANBgkqh…" long string is the actual public signing key. The receiving server uses this key to verify the DKIM signature.
  

Getting DKIM Record Values
Just like with SPF record values, you can usually find the exact DKIM values (including the selector for use in the Host/Name DNS field) by looking at your sending platform's deliverability documentation.

Summary
DKIM is important to set up properly, especially as it's one of the authentication methods that tends to be best DMARC-aligned and pass most consistently. We hope this article has helped clarify some of the confusion around DKIM record setup!