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 work in conjunction with each other 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

The DKIM Process

The process for DKIM authentication involves a pair of cryptographic keys — one private (held by the sending server) and one public (published in your DNS records). Here's how they work together:

DKIM Encryption/Decryption

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 it, 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), 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 DKIM, the sender uses their own private key to sign, and anyone can use the corresponding public key to verify that signature.

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 the authenticity (the email actually originated from the claimed domain).

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.

The purpose of DKIM is not to keep email content confidential (that would be the role of encryption), but to verify its authenticity and integrity. Luckily, as a typical email sender, you don't need to understand all of the inner workings — you just need to make sure your DKIM record configuration and values are correct.

Creating a DKIM Record

Just like SPF and DMARC records, the DKIM record is a TXT type record you add to your DNS records. A typical DKIM record has two main parts: the host name and the record value.

The Host Name

A DKIM host name looks something like google2._domainkey.us. Let's break it down:

• google2. — This is called the selector. It's chosen by each of your sending platforms and conveyed to you during setup. The selector helps receiving servers run a lookup to find the DKIM record for that particular platform and locate the signing public key.
• _domainkey — The accepted syntax for identifying the TXT record as a DKIM record.
• .us — References the subdomain that the DKIM record is placed on. If you're setting the DKIM record on the root domain, it would simply be google2._domainkey.

The Record Value

The record value contains the actual cryptographic information:

• v=DKIM1 — Identifies this TXT record as a DKIM record. The “v” stands for version (version 1).
• k=rsa — Indicates the key type. RSA is an encryption algorithm widely used in public-key cryptography (the method DKIM verification relies on).
• p=MIIBIjANBgkqh... — The actual public signing key. This long string is what the receiving server uses to verify the DKIM signature attached to your emails.

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.

Common platforms and where to find their DKIM setup instructions:

• Klaviyo — Settings → Email → Domains → DNS Records
• Mailchimp — Settings → Domains → Authenticate
• Google Workspace — Admin Console → Apps → Google Workspace → Gmail → Authenticate Email

Each sending platform will have its own unique selector value. Unlike SPF records where you can only have one per domain, you can have as many DKIM records as needed — just make sure each has a unique selector.

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. The key things to remember:

• DKIM verifies email integrity (content wasn't tampered with) and authenticity (it came from your domain).
• You need a DKIM record for every sending platform you use.
• Multiple DKIM records are fine — they just need unique selectors.
• DKIM works alongside SPF and DMARC as part of the email authentication trio.