DKIM: The Crypto Behind Email Authentication That Actually Works

First time I saw a DKIM-Signature header in the wild I had to look up what all those fields meant. That was back in 2005, and DKIM was still experimental. These days it's the difference between your email landing in the inbox or getting flagged as spam.

DKIM signs your outgoing emails with a cryptographic key. The receiving server checks the signature against a public key in your DNS. If it matches, the email is legit and hasn't been tampered with.

Think of it like a tamper-evident seal on a package. The seal alone doesn't prove who sent it, but combined with DNS, it does.

Why You Need DKIM

SPF checks the envelope sender. That works great until someone forwards the email. Once it's forwarded, the SPF check runs against the forwarder's server, which isn't authorized in your SPF record. SPF breaks. DKIM doesn't.

Here's the practical impact:

DKIM survives email forwarding. SPF does not.

Google and Yahoo require either SPF or DKIM to pass for DMARC alignment.

DMARC gives you reporting. Without DKIM, your DMARC reports are incomplete.

Major providers weigh DKIM more heavily in their spam algorithms.

If you only implement one authentication method, make it SPF. But if you want your email to actually land in the inbox instead of spam, implement DKIM too.

How the Signing and Verification Work

DKIM uses RSA public-key cryptography. You generate two keys:

A private key that lives on your mail server. This never leaves your server.

A public key that goes into your DNS. This is what everyone can see.

The Signing Process

When your mail server sends an email:

It takes specific headers (From, To, Subject, Date, Message-ID) and the email body.

It hashes those pieces together.

It encrypts the hash using your private key.

It adds a DKIM-Signature header to the email containing the encrypted hash and metadata.

The Verification Process

When a receiving server gets the email:

It extracts the DKIM-Signature header.

It reads the selector (s=) and domain (d=) from the signature.

It queries DNS at [selector]._domainkey.[domain] to get your public key.

It decrypts the signature using the public key and compares it to a freshly computed hash of the email content.

If they match, DKIM passes. If they don't, DKIM fails and the email is treated as suspicious.

The beauty of this system is that the private key never leaves your server. Even if someone compromises your DNS and replaces your public key, they'd need the corresponding private key to sign emails. And they don't have it.

DKIM Selectors

The selector is a label that identifies which public key to use. You can have multiple selectors active at the same time. This is how you rotate keys without breaking in-flight emails.

Here are the selectors I've collected over the years:

Our DKIM Lookup tool tries 55+ selectors automatically. If you don't know your selector, start there.

Setting Up DKIM

Google Workspace

Go to admin.google.com > Apps > Gmail > Authenticate Email.

Select your domain and click Generate New Record.

Google shows you a TXT record for google._domainkey.yourdomain.com.

Copy the record value and publish it in your DNS.

Wait for propagation and click Enable.

Microsoft 365

Open the Microsoft 365 Defender portal.

Go to Email & Collaboration > Policies & Rules > Email Authentication > DKIM.

Select your domain and create the DKIM keys.

Microsoft gives you two CNAME records (selector1 and selector2).

Add them to your DNS and enable signing.

Generic Setup (Any Provider)

Enable DKIM in your provider's admin panel.

Get the DNS record they give you.

Publish it at [selector]._domainkey.yourdomain.com as a TXT record.

Verify with our DKIM Lookup tool.

Toggle signing on.

What a DKIM-Signature Header Looks Like

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=google; t=1721234567;
 bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 h=from:to:subject:date:message-id;
 b=dzdVyOfAKCdXwPKbUqIxhDNEvCw2gQhLUKHv6QuGmHXL
  8UxVxQJq3fM7PqWZcRZq7v3WJLX9CQ5eFJ2r4Y6NZA==

The fields:

v: Version (always 1).

a: Signing algorithm.

c: Canonicalization method for headers/body.

d: Domain that signed the email.

s: Selector for looking up the public key.

t: Timestamp of when the signature was created.

bh: Body hash (base64-encoded).

h: Colon-separated list of signed headers.

b: The actual signature (base64-encoded).

DKIM Best Practices From the Trenches

Rotate Your Keys Every 6 Months

I schedule this in my calendar. Generate a new key pair, publish the new public key under a new selector, switch your mail server to sign with the new selector, then remove the old one after two weeks. This limits the damage if a key is compromised.

Use 2048-Bit Keys

Some providers default to 1024-bit. That's still secure, but 2048 gives you a wider safety margin. The performance cost is negligible. If your provider allows it, use 2048.

Never Put Your Private Key in DNS

I've actually seen this in production. Someone pasted the wrong file. The entire internet had access to their signing key. The public key goes in DNS. The private key stays on your server. These are different files.

Test Your Signature Regularly

Send an email to a test address, pull the raw headers, and check the signature. Or drop the headers into our Header Analyzer. It shows you exactly what the receiving server saw.

Common DKIM Failures and Fixes

Verify Your DKIM Setup

Use the DKIM Lookup tool to check your public key in DNS. Use the Header Analyzer to check the signature on a real email you've sent. If both pass, you're good.