DKIM explained: how cryptographic signing keeps your email trusted

What DKIM is

DKIM — DomainKeys Identified Mail — adds a cryptographic signature to every outbound message. The signature is computed over the message body and selected headers, using a private key that lives on your mail server (or your ESP’s). The matching public key is published in DNS at a specific subdomain. When a receiver gets your message, it fetches the public key from DNS and uses it to verify the signature.

If the signature verifies, DKIM passes. The receiver now knows two things: (1) the message came from someone in control of the private key, and (2) the message body and signed headers haven’t been tampered with in transit.

Why DKIM is more important than SPF

DKIM survives forwarding. If a recipient forwards your message to another address, the envelope rewrites and SPF fails — but the DKIM signature travels with the message body, intact. Anywhere that forwarded message lands, DKIM can still verify.

That property is why DMARC requires either SPF or DKIM to pass and align with the visible From: domain. In practice, DKIM alignment is the more reliable path.

The DKIM signature in the message

Open a real message in your inbox and you’ll see something like this in the headers:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=mail2026; t=1737382800;
    h=from:to:subject:date:message-id;
    bh=A0u7T3F...=;
    b=cVtVw9F...

Reading the fields:

• v=1 — DKIM version.
• a=rsa-sha256 — signing algorithm. RSA-SHA256 is the universal standard; Ed25519 is supported but rarely used.
• c=relaxed/relaxed — canonicalization for headers/body. Relaxed normalizes whitespace; simple is bit-exact.
• d=example.com — the signing domain. This is the one that gets aligned with the visible From:.
• s=mail2026 — the selector. Combined with the domain, it tells the receiver where to look up the public key.
• h=from:to:subject:date:message-id — which headers are covered by the signature.
• bh=... — hash of the body.
• b=... — the signature itself.

The DNS record

Given d=example.com and s=mail2026, the receiver looks up:

mail2026._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

p= is the base64-encoded public key. The selector is whatever you like — common conventions are dates (mail2026, 2026jan), services (google, mailchimp), or generic (s1, default).

How to set up DKIM

You don’t generate DKIM keys by hand if you can avoid it. Every modern ESP — Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, AWS SES, Mailchimp — has a “Set up DKIM” wizard that gives you a TXT record (or a CNAME) to drop into DNS.

Typical flow:

1. Log into your ESP, find the DKIM / sender authentication section.
2. Copy the TXT (or CNAME) record they show you.
3. Paste it into your DNS provider, on the correct selector subdomain.
4. Click “Verify” in the ESP. It usually takes a few minutes for DNS to propagate.
5. Send a test message to yourself and verify dkim=pass in the Authentication-Results header.

For self-hosted mail (Postfix + OpenDKIM, for instance), you generate a key pair, publish the public key in DNS, and configure OpenDKIM to sign with the private key. The OpenDKIM docs cover this — but for the marketing-vs-ops audience, “use your ESP’s wizard” is the right advice 95% of the time.

Rotating DKIM keys

DKIM keys should rotate. The reason is straightforward: a leaked private key lets an attacker forge mail as you, and a rotated key invalidates any compromised one.

Rotation is easy because the selector lets two keys coexist. You add the new selector (mail2026feb) with a fresh public key, switch your mail server to sign with the new private key, and leave the old selector in DNS for a couple of weeks to verify any in-flight or forwarded mail. Then you remove the old selector.

A practical cadence is once every 6 to 12 months, plus immediately if you suspect compromise.

The four most common DKIM mistakes

1. Missing DKIM entirely. Many small senders rely on SPF alone and never set up DKIM. DMARC can pass on either, but DKIM is what survives forwarding — and Gmail/Yahoo now expect both for bulk mail.
2. Wrong signing domain. If your d= doesn’t align with your visible From: domain (or an organizational parent), DMARC fails alignment even though DKIM itself passed. ESPs sometimes default to signing with their own domain unless you opt into “authenticated domain” / “DKIM for your domain” — that’s the setting to find.
3. Truncated public key. DKIM public keys in DNS frequently exceed the 255-character TXT segment limit and need to be split into multiple quoted strings within one TXT record. Some DNS providers do this for you; some don’t, and you end up with a truncated key that won’t verify.
4. Forgetting to publish the public key before sending. If you flip on DKIM signing in your mail server before publishing the DNS record, every message hits receivers with a signature that can’t be verified — and dkim=permerror is worse than no DKIM at all in many filters.

How Email Health Pro grades DKIM

We verify the signature, confirm the public key resolves, check the algorithm and key strength, and verify the signing domain aligns with the visible From: for DMARC purposes. We also surface the selector, key size, and signed headers so you can sanity-check what’s actually being protected.

Up next: DMARC, which ties SPF and DKIM together into an actual policy.