Tutorials

How DKIM Email Signing Works: Cryptography Without the Math

Published 2026-06-02

DKIM in plain English: how cryptographic signatures prove an email wasn't forged or tampered with in transit, and why it's the harder half of email authentication.

What DKIM Does

DKIM (DomainKeys Identified Mail) lets a sending mail server cryptographically sign outgoing messages, and lets receiving mail servers verify the signature. A valid signature proves two things: the message really did come from a server authorised by the domain owner, and the message body and signed headers haven't been altered in transit.

The Two-Key Setup

DKIM uses asymmetric cryptography — a private key (kept secret on the sending mail server) and a public key (published in the domain's DNS).

The sending server uses the private key to compute a signature over the message body and selected headers
The signature is attached to the outgoing message as a DKIM-Signature: header
The receiving server reads the header, finds the public key in DNS, and verifies the signature
If the signature verifies, the message is genuine and unaltered

Anatomy of a DKIM Signature

A typical DKIM-Signature: header includes:

v=1 — version
a=rsa-sha256 — the signing algorithm
d=example.com — the signing domain
s=selector1 — the selector (lets one domain have multiple keys)
h=From:To:Subject:Date — which headers are included in the signature
bh=... — the body hash
b=... — the actual signature

The selector is the trick that lets a domain rotate keys without downtime: publish the new public key at newselector._domainkey.example.com, start signing with the new selector, then retire the old key after a grace period.

Where Public Keys Live

A DKIM public key is a DNS TXT record at <selector>._domainkey.<domain>. For example, Gmail uses 20221208._domainkey.gmail.com. Check with:

dig +short TXT 20221208._domainkey.gmail.com

The record contains v=DKIM1; k=rsa; p=<base64-encoded public key>.

What DKIM Doesn't Protect

Headers that weren't included in the signature (the h= list). If Subject: wasn't signed, an attacker who intercepts the message could replace the subject without breaking the signature.
Encryption in transit. DKIM proves authenticity; it doesn't encrypt the content. Use TLS for that.
The recipient. DKIM verifies the sender, not who the message is for.

Why It's the Hard Half

SPF is a one-line TXT record. DKIM requires:

Generating an RSA key pair (or using a managed key from a transactional-email provider like SendGrid)
Publishing the public key in DNS
Configuring your mail server to sign with the private key
Rotating keys periodically (good practice, though not strictly required)

Most small senders skip DKIM and rely on SPF alone. The result is that their mail occasionally lands in spam at strict receivers (Gmail, Outlook), even when not spam.

Practical Takeaway

If you receive an email and want to verify it cryptographically, view its raw source and look for the DKIM-Signature: header. Compare the d= domain to the visible From: domain. If they match and the signature verifies (Gmail shows this in 'Show original'), the message is cryptographically authenticated. If they don't match, it's either a legitimate third-party-sent message (newsletter platforms, contact forms) or a spoof.