What is DKIM?

DKIM is the cryptographic signature on your email — the second pillar of modern email security, alongside SPF and DMARC.

In a nutshell

DKIM stands for DomainKeys Identified Mail. When you send a message, your mail server signs certain header fields and the body with a private key. The corresponding public key lives in your domain's DNS — the receiving server fetches it, verifies the signature, and confirms beyond doubt that the message really came from one of your mail servers and wasn't tampered with on the way.

Why isn't SPF enough?

SPF only checks whether the sending IP is authorized. But if the message is forwarded along the way (the classic mailing-list or forwarding case), the sending IP changes — and SPF fails, even though the message is legitimate. DKIM, by contrast, travels with the message: the signature stays valid no matter how many hops the message makes. That makes DKIM the more robust authentication — and that's exactly why DMARC requires SPF or DKIM to pass.

How does the signature work?

Every DKIM-signed message carries a DKIM-Signature header. It looks roughly like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=mail2024;
  h=from:to:subject:date:message-id;
  bh=base64(BodyHash);
  b=base64(Signature)

d=... — the signing domain.
s=... — the selector (key name).
h=... — list of signed header fields.
bh=... — hash of the email body.
b=... — the signature itself.

The recipient fetches the public key from {selector}._domainkey.{domain}, for example mail2024._domainkey.example.com, and verifies the signature. If it matches, the message is authenticated.

What are selectors?

Selectors let you run multiple DKIM keys in parallel — for instance, one for transactional mail (order confirmations), one for newsletters (Mailchimp, Brevo), and one for CRM mail. Each sender uses its own selector with its own DNS entry. Common default selectors: default, google, selector1, selector2, k1, mail, s1.

Key rotation

DKIM keys should be rotated every 6–12 months. Recommended workflow:

Create a new selector (e.g. mail2025) and publish the new public key in DNS.
Switch the mail server to the new selector — from now on it signs with the new key.
Keep the old selector reachable for at least 1–2 weeks in case messages signed with the old key are still in flight.
Remove the old DNS entry.

Common pitfalls

Key too short: At least 1024-bit RSA, ideally 2048-bit. Shorter keys are vulnerable to attack.
Body modification: Mailing lists that append footers break the signature. Solution: use c=relaxed/relaxed — it tolerates whitespace changes.
Wrong d= domain: DMARC alignment fails when the signing domain (d=) doesn't match the From domain.
Forgotten selectors: When you switch newsletter providers, the old selector often stays in DNS — it's harmless but useless. Clean it up anyway.