DKIM explained: how to sign your emails and why it matters

SPF answers one question: "is this IP allowed to send for this domain?" DKIM answers a harder one: "was this message actually written by someone who controls this domain, and has anyone tampered with it in transit?" The two mechanisms overlap on intent but not on coverage, which is why Gmail, Yahoo and every serious ISP now require both.

Why DKIM exists

SPF only authenticates the connecting IP. It can't tell you whether the body or headers were modified mid-journey, and it doesn't survive forwarding. If a user auto-forwards a message from their university address to Gmail, the SPF check breaks completely — the forwarding server isn't in your SPF record.

DKIM fixes both. The signature is attached to the message itself, so any intermediate server that doesn't rewrite headers or body will still deliver a valid signature. And because it's a hash, any edit to the signed portions invalidates it.

The 30-second crypto primer

DKIM uses asymmetric cryptography. You generate a key pair: the private key stays on your mail server, the public key goes into DNS as a TXT record. When your server sends a message, it hashes specific headers plus the body, encrypts that hash with the private key, and attaches the result as a DKIM-Signature header.

When a receiver gets the message, it looks up your public key in DNS, decrypts the signature, recomputes the hash itself, and compares. If they match, the message is authenticated as originating from someone who controls that private key — which, barring a compromise, is you.

What DKIM signs

A DKIM signature covers two things:

• A list of headers specified by the h= tag. Typically From, To, Subject, Date, Message-ID, plus Content-Type. The From header is essentially always signed.
• A hash of the body, stored in the bh= tag.

The two values are then signed together and stored in the b= tag of the DKIM-Signature header. Anything not in h= is fair game for intermediate servers to edit without breaking the signature — which is why Received headers aren't signed.

DKIM-Signature header anatomy

A real DKIM-Signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD0...

Each tag:

• v=1 — DKIM version, always 1.
• a=rsa-sha256 — signing algorithm. RSA-SHA256 is the modern default; older RSA-SHA1 is deprecated.
• d=example.com — the signing domain. This is the tag DMARC alignment cares about.
• s=selector1 — the selector, used to build the DNS lookup.
• c=relaxed/relaxed — canonicalisation for headers/body. Relaxed tolerates whitespace and case differences; simple does not.
• h= — the list of headers covered.
• bh= — body hash.
• b= — the actual signature.

Selectors

A selector is a short name that lets you publish multiple public keys under the same domain. It's the part of the DNS query before _domainkey. If your DKIM-Signature says d=example.com and s=mail2026, the receiver looks up:

mail2026._domainkey.example.com

Selectors serve three purposes. They let you run multiple signers in parallel (different ESPs, different keys). They let you rotate keys without downtime — publish the new selector, start signing with it, then retire the old one. And they isolate breaches: if a private key leaks, you can rotate that one selector without touching anything else.

Good practice: rotate keys every 6–12 months, keep the previous selector live for a week after switching so mail in-flight still verifies, then remove the old TXT record.

The d= domain vs From domain

The signing domain (d=) is arbitrary — anyone who controls any domain can sign any message. What makes the signature meaningful is alignment: does d= match (or share an organisational parent with) the domain in the visible From header?

This is the whole point of DMARC. A signature from d=sendgrid.net on a message From: you@brand.com passes DKIM but fails DMARC alignment. To make DMARC happy, you configure your ESP to sign with d=brand.com, which means delegating DKIM via CNAME records the ESP provides. Every serious ESP supports this.

Key size: 1024 vs 2048-bit

The choice is between 1024-bit and 2048-bit RSA keys. 2048 is the modern recommendation — it's what Gmail and Microsoft use internally. The tradeoff: some DNS providers still truncate TXT records over 255 characters, and a 2048-bit public key typically exceeds that, requiring the record be published as concatenated multiple strings. Most providers handle this transparently; a few still don't.

If you have a choice, pick 2048-bit. If your DNS provider mangles it, switch DNS providers before dropping to 1024-bit — vendors like Cloudflare, Route 53 and Google Cloud DNS all handle long TXT records correctly.

Setup walk-through

The generic flow across every ESP:

1. In the ESP admin panel, enable DKIM for your sending domain.
2. The ESP generates a key pair and shows you one or more DNS records — typically a TXT record at a selector, or a CNAME pointing to a record the ESP maintains.
3. Publish those records in your DNS provider exactly as shown.
4. Wait for DNS propagation (TTL-dependent, usually under 30 minutes).
5. Click "Verify" in the ESP. It does a DNS lookup to confirm the public key is live.
6. Send a test message to a Gmail address and check Show original. Look for dkim=pass in the Authentication-Results header.

Verifying DKIM works

The simplest check: send yourself a message at Gmail, open it, click the three-dot menu, choose "Show original." Near the top you'll see:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@brand.com header.s=selector1 header.b=dzdVy...

dkim=pass with header.i=@brand.com matching your From domain — that's a good signature. Tools like Mail-Tester, MXToolbox Email Headers and dmarcian's analyser parse this automatically.

Common errors

• Selector not published. The signing server uses selector s1 but you published s2 in DNS. Every message fails.
• Key mismatch. You regenerated keys on the server but forgot to update DNS. Old cached public key no longer decrypts new signatures.
• Body-altering footer services. Some list servers and mail security gateways rewrite the body to add legal footers. This invalidates the body hash. Fix: sign after the footer is added, or disable the footer.
• CNAME pointing at the wrong target. Common with Mailchimp and SendGrid setups. Copy the target exactly as the ESP provides.
• Multiple domains, one selector. You can't have two senders sign with d=brand.com; s=default and different keys — one will fail. Use different selectors per vendor.

Frequently asked questions