DKIM Explained: The Signature Behind Every Trusted Email

SPF tells the world which servers may send mail for your domain. DMARC tells receivers what to do when authentication fails. Neither one says anything about the message itself. A server can be perfectly SPF-authorised and DMARC-policied while delivering a message whose subject line was rewritten in transit by some intermediate relay — and SPF and DMARC will both happily say everything is fine.

DKIM is the part of email authentication that fills that gap. It attaches a cryptographic signature to the message before it leaves the sender, and the receiver verifies that signature against a public key the sender published in DNS. Any change to the signed headers or body — a flipped character in the subject, an injected disclaimer, a rewritten link — breaks the signature, and the receiver knows the content can't be trusted. It's not about who connected. It's about whether the message is exactly the one that was sent.

What DKIM actually does

DomainKeys Identified Mail (RFC 6376) is digital signing for email. When a mail server signs an outgoing message, it picks a set of headers (almost always including From:, Subject:, To:, Date:, Message-ID:) plus the body, hashes those, signs the hash with a private key, and stamps the result onto the message as a new header called DKIM-Signature. The public key — the counterpart needed to verify the signature — is published in DNS as a TXT record at a predictable location: {selector}._domainkey.{domain}.

When a receiver gets the message, it reads the DKIM-Signature header to learn (a) which domain claims to have signed and (b) which selector to use. It looks up the public key in DNS, recomputes the hash over the same headers and body, decrypts the stored signature with the public key, and compares. Match → the message hasn't been altered since the signing server let it go. No match → something between the signer and the receiver touched the bytes, and the receiver should treat the signature as broken.

The cryptography is plain asymmetric signing — RSA in almost every deployment, with Ed25519 starting to appear. There's no magic. What DKIM adds on top of "use crypto" is the DNS-based key distribution (you publish the public key once, anyone in the world can fetch it) and the canonicalisation rules (a way to compute the hash that tolerates minor whitespace tweaks made by intermediate servers without breaking the signature outright). Those two pieces together are what make DKIM workable at internet scale.

Reading a DKIM-Signature header

Every signed message carries a header that looks something like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=google;
  h=from:to:subject:date:message-id;
  bh=BASE64_BODY_HASH;
  b=BASE64_SIGNATURE

Picking the tags apart:

• v=1 — the DKIM version. There's only one. If a receiver sees anything other than 1, it ignores the signature.
• a=rsa-sha256 — the signing algorithm. rsa-sha256 is what everyone uses. rsa-sha1 was the original and is now deprecated; ed25519-sha256 is the modern alternative that hasn't taken over yet.
• c=relaxed/relaxed — the canonicalisation modes for the header and body, respectively. "Relaxed" lets receivers tweak whitespace and case in ways that real-world mail relays routinely do; "simple" is strict (any change at all breaks the signature). Almost all senders use relaxed/relaxed because simple is too fragile.
• d=example.com — the signing domain. This is what DMARC's alignment check looks at. It does not have to match the From: domain; alignment is what makes them line up later.
• s=google — the selector. Combined with d=, this tells the receiver where to fetch the public key: google._domainkey.example.com.
• h=from:to:subject:date:message-id — the list of headers that were signed, in order. The receiver re-hashes these exact headers in this exact order. A header not in the list isn't covered by the signature, so an attacker could in principle add or alter it without breaking anything — which is why From: and Subject: in particular should always be there.
• bh=… — the body hash. The signer hashed the (canonicalised) message body and base64-encoded the result. The receiver redoes the calculation and compares.
• b=… — the signature itself. The signer signed (with the private key) a string built from the header tags plus the body hash. The receiver decrypts it with the public key and checks it matches what they re-computed.

The receiver verifies both the body hash and the signature. If either fails, DKIM fails. If both succeed, the message hasn't been altered in any of the signed parts since it left the signing server.

Selectors, and why DKIM is plural

A domain doesn't have one DKIM key — it can have as many as it likes, each living at a different selector. The full DNS name of a public key is {selector}._domainkey.{domain}. For example.com with selector google, you'd look up:

google._domainkey.example.com

That TXT record contains the public key. The selector itself is just a label the domain owner picked. There's no central registry of selectors; you make up whatever name you want and tell your mail platform to sign with it.

Multiple selectors exist for two reasons. The first is multiple senders. A typical company sends transactional mail through one service (say, SendGrid), marketing through another (Mailchimp), and corporate mail through Google Workspace. Each of those services signs with its own key under its own selector. Google Workspace publishes a key at google._domainkey.example.com. Mailchimp uses k1._domainkey.example.com. SendGrid uses s1._domainkey.example.com and s2._domainkey.example.com. Microsoft 365 uses selector1._domainkey.example.com and selector2._domainkey.example.com. All of these coexist peacefully because they're at different DNS names.

The second reason is key rotation, which we'll get to in a second. The fact that selectors are arbitrary is also why a DKIM lookup tool can't ask "what's your DKIM key?" — there's no canonical answer. Tools have to either be told which selector to check, or probe a long list of common selectors and report which ones return a key. The DKIM lookup tool probes 50+ of them in parallel.

Why you rotate DKIM keys

RSA private keys live on mail servers. Mail servers get compromised. Backups leak. Engineers leave. If your DKIM private key ends up in the wrong hands, an attacker can forge signed mail from your domain that passes every DKIM check perfectly, indistinguishable from genuine messages — at least until you rotate the key out of service.

The rotation itself isn't dramatic. You generate a new key pair. You pick a new selector — typically a fresh date or version label like 2026q2 or 20260511. You publish the new public key in DNS, alongside the old one. You configure the mail server to start signing with the new key. After enough time has passed that any in-flight messages with the old signature have been delivered (usually a week), you remove the old public key by either deleting the DNS record or, by convention, replacing its p= tag with an empty value (p=) to explicitly mark it as revoked.

Some platforms automate the whole cycle. Google Workspace, for example, rotates Gmail's DKIM keys on its own infrastructure with date-based selectors that bake the year and month into the selector name; you just publish the right CNAME or TXT records once and Google handles the rest. For self-hosted mail servers, you do the rotation by hand or with a tool like opendkim-genkey on a quarterly or yearly cadence.

Key length matters

DKIM's security rests entirely on the strength of the asymmetric key. There are three points worth knowing:

• 1024-bit RSA was the original standard and you still see it deployed widely, but it has been NIST-deprecated for years. Cracking a 1024-bit key is not yet routine but is well within reach of a sufficiently motivated and well-resourced attacker. Don't ship new infrastructure on 1024-bit.
• 2048-bit RSA is the current minimum recommended length and what every modern platform defaults to. It's slower and longer (the public key encoded as base64 frequently overflows a single 255-character TXT string and has to be split — more on that in a moment), but it's the right tradeoff.
• Ed25519 is the emerging alternative. The keys are tiny — a public key fits comfortably in a single TXT string — and signing is dramatically faster than RSA. Most large receivers (Gmail, Outlook, Yahoo) now accept Ed25519 signatures, but support isn't yet universal, so the typical Ed25519 deployment publishes a parallel RSA signature for fallback.

Our DKIM tool grades key length on a sliding scale: 1024 is flagged as weak, 2048 is "strong," 4096 is "very strong," anything shorter is "broken." If you're still on 1024-bit RSA, rotate to 2048 the next time you have a maintenance window. The migration is the same shape as any other rotation: new selector, new key, parallel publish, switch signing, retire the old one.

Common DKIM problems

The failures we see most often when running the DKIM lookup against real domains:

• Key too short. 1024-bit RSA still in production. The signatures verify fine, but the security margin is thin. Rotate to 2048.
• The record is too long for a single TXT string. DNS TXT records have a hard 255-character per-string limit, and a base64-encoded 2048-bit RSA public key is comfortably longer than that. The correct fix is to split the value into multiple quoted strings, which the resolver concatenates into a single logical record. If the DNS host doesn't support multi-string TXT — some don't — the workaround is usually a CNAME pointing at a key hosted by the sending platform.
• Only some headers signed. The h= tag covers a subset of headers. If Subject:, From:, or Reply-To: aren't in that subset, an attacker can rewrite them after signing and the signature still verifies. Reasonable defaults always include at least from, to, subject, date, message-id, and the platform's own correlation headers.
• No key rotation after a breach. The mail server got compromised six months ago; the key is still in DNS. Every signed message an attacker sent during that window verifies, and will continue to verify, until the key is revoked.
• Multiple keys at the same selector. Two TXT records at {selector}._domainkey.{domain} — usually because someone added a new key without removing the old one. Some receivers pick the first; others reject both. The fix is to publish each key at its own selector, not stack them at one name.
• The published p= tag is empty. An empty p= tag is the protocol's "this key is revoked" signal. Some operators accidentally publish it during a rotation, breaking every in-flight signature. Make sure the new key is in place and being signed with before retiring the old one.

DKIM + SPF + DMARC, together

The three protocols solve different problems and lock together only when all three are in place:

• SPF authenticates the connecting server — was this IP authorised to send for the envelope domain? (See SPF Records Explained for the full mechanics, including the 10-lookup ceiling.)
• DKIM authenticates the message content — was this exact body and these exact signed headers produced by someone who holds the private key for the signing domain?
• DMARC ties them together — was at least one of those checks aligned with the visible From: domain, and what should the receiver do if not? (See DMARC Explained for alignment, the three policies, and the reporting feedback loop.)

SPF is the server. DKIM is the message. DMARC is the rule that joins them.

Each layer has a separate failure mode. SPF can break on forwarding because the forwarder's IP isn't authorised. DKIM can break if any intermediate server rewrites a signed header. DMARC catches the combined result and decides whether to deliver. The reason all three exist together is that no single one is strong enough on its own — and the reason large receivers like Gmail, Outlook, and Yahoo now require DMARC for bulk senders is that none of the protocols is optional in practice anymore.

If you operate a domain that sends mail, check all three. The SPF checker walks the include tree and counts you against the lookup ceiling. The DMARC checker grades your policy. The DKIM lookup tool probes every common selector, grades the key strength, and flags broken records. And the email header analyzer takes a specific message and shows you the SPF, DKIM, and DMARC results inline, so you can debug a single delivery problem instead of guessing about a whole domain.