Learn · Email authentication

What is DKIM?

DKIM (DomainKeys Identified Mail) puts a cryptographic signature on every message your servers send. Receivers verify it against a public key you publish in DNS — proving the mail genuinely involved your domain and wasn't altered in transit. Of DMARC's two inputs, DKIM is the sturdier one.

How it works

When your mail server (or your ESP) sends a message, it computes a signature over the body and selected headers using a private key, and attaches it as a DKIM-Signature header (RFC 6376). The two tags that matter most:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
  h=from:to:subject:date; bh=…; b=…

• d= — the signing domain: who vouches for this message.
• s= — the selector: which of the domain's keys was used.

The receiver fetches the public key from DNS at <selector>._domainkey.<domain> — here, mail2026._domainkey.example.com — and verifies the signature. If it verifies, DKIM passes for example.com: the mail's signed content is exactly what a holder of that domain's key sent.

Selectors: many keys, one domain

Selectors let a domain publish any number of keys at once. That's what makes DKIM practical: Google Workspace signs with its selector, your marketing platform with another, your billing system with a third — each service gets its own key, and you can revoke or rotate any of them without touching the rest. It's also why setting up a new sending service always involves pasting one or two CNAME or TXT records into DNS: you're publishing that service's public key under your domain.

Why DKIM survives forwarding (and when it doesn't)

Unlike SPF — which fails the moment a forwarder's IP delivers your mail — a DKIM signature travels inside the message. A simple forward that doesn't modify the message leaves the signature verifiable. That makes DKIM the check that keeps DMARC passing for forwarded mail, and it's why you should sign everything even when SPF looks sufficient.

It's not indestructible: anything that modifies the signed content breaks it. The classic case is mailing lists that add a subject-line tag or an unsubscribe footer. ARC exists to help receivers make fair decisions in exactly those cases.

When a source shows both SPF and DKIM failing, forwarding is one of three usual explanations — an unaligned vendor and genuine spoofing are the others, and they need very different responses. How to tell them apart.

DKIM and DMARC alignment

For DMARC, a passing DKIM signature only counts if the signing domain (d=) matches the domain in the visible From header. A message signed d=mailchimp.com passes DKIM but does not make DMARC pass for a From of you@yourbrand.com — the pass belongs to the wrong domain. Every serious sending service offers custom DKIM signing with your own domain in d=; turning that on is usually the single highest-impact step toward DMARC compliance. Your aggregate reports show exactly which domain each signature carried.

Checklist

1. Every service that sends as your domain signs with DKIM — and signs with your domain in d=, not the service's own.
2. Keys are 2048-bit; retired services' keys are removed from DNS.
3. Forwarding-heavy recipients (schools, associations, some corporates)? DKIM is what keeps your mail passing DMARC there — don't rely on SPF alone.
4. Watch your reports for signatures with unexpected d= domains: it's the fastest way to spot a service that was never configured properly.