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.

The signature is there but does not verify

A report row can carry a DKIM signature for your own domain and still show dkim=fail. That is a different problem from the misaligned d= above: the sender did sign as you, and the receiver could not verify it. The report names the selector, and that is where to look. Query selector._domainkey.yourdomain.com — the DKIM checker does it for you — and compare what is published with what the sender expects.

Three causes cover nearly every case. The key was rotated at the sender but the DNS record was never updated, common with services that ask you to publish a raw TXT record rather than a CNAME. The record was mangled when it was pasted, usually a 2048-bit key split across strings with a space or a missing character. Or the message was altered in transit by a gateway that rewrote the subject or added a footer, in which case the failures cluster at a few recipients and your own key is fine. If the first two check out and the failures are broad, re-issue the key from the sender and publish it as the CNAME the vendor offers, so future rotations happen without you.

Which of the three you are looking at is usually stated outright in the failing message: the reason beside dkim=fail distinguishes a body hash mismatch from a signature that did not verify, and separates both from neutral and temperror, which mean the receiver never reached a verdict.

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.