DKIM Signature
A DKIM signature is a cryptographic signature added to an email's headers (the DKIM-Signature header) that lets receivers verify the message was authorized by the sending domain and wasn't altered in transit. Key tags include d (domain), s (selector), b (signature) and bh (body hash).
This guide is part of our complete guide to DKIM. Related: the DKIM record and why DKIM fails.
A DKIM signature is a cryptographic signature added to an email’s headers — carried in the DKIM-Signature header — that lets a receiving server verify the message was authorized by the sending domain and has not been altered in transit. The signature is generated with a private key held by the sender and checked against a matching public key published in DNS.
What the DKIM-Signature header looks like
The signature travels as a single header field prepended to the message. It packs everything a receiver needs — the signing domain, the selector, which headers were signed, a hash of the body, and the signature itself — into a series of tag=value pairs separated by semicolons.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=selector1; t=1700000000;
h=from:to:subject:date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=Cg5Xje8kY0m5xT1pW2qL4vN8rH6dF3aZ9cU7bE0iQoR2sT4uV6wX8yZ1
aB3cD5eF7gH9jK2lM4nP6qR8sT0uV2wX4yZ6aB8cD0eF2gH4jK6l=
The header is inserted by the sender’s mail server before the message leaves the domain. Line breaks and indentation are only for folding — the value is logically one continuous string.
The tags in a DKIM signature
Each tag carries one piece of the verification puzzle. The signer chooses these values; the verifier reads them back to reconstruct and check the signature.
| Tag | Name | Purpose |
|---|---|---|
v | Version | DKIM version. Always 1. |
a | Algorithm | Hash and signing algorithm, e.g. rsa-sha256 or ed25519-sha256. |
d | Domain | The signing domain — the identity DKIM authenticates. |
s | Selector | Names which public key to fetch from the domain’s DNS. |
h | Signed headers | Colon-separated list of header fields covered by the signature. |
bh | Body hash | Hash of the (canonicalized) message body. |
b | Signature | The actual cryptographic signature, base64-encoded. |
c | Canonicalization | How headers/body are normalized before hashing, e.g. relaxed/relaxed. |
t / x | Timestamps | t is when the message was signed; x is when the signature expires. |
How signing works (on send)
When a message leaves the sending server, DKIM does two things. First it canonicalizes the body and hashes it, storing the result in bh. Then it canonicalizes the headers named in h — along with the DKIM-Signature header itself (with an empty b) — hashes that block, and signs the hash with the domain’s private key. The resulting signature becomes the b value. Because the private key never leaves the sender, only the true domain owner can produce a signature that will validate.
How verification works (on receipt)
The receiving server reads the DKIM-Signature header to learn the domain (d) and selector. It queries DNS at <selector>._domainkey.<domain> to fetch the public key from the DKIM record. It then repeats the sender’s work: it canonicalizes and hashes the body, compares that against bh, canonicalizes and hashes the signed headers, and uses the public key to check b against that header hash. If both the body hash matches and the signature verifies, DKIM passes. The bh check is what catches any tampering with the message body — even a single changed character produces a different hash and fails the check.
When signatures fail
A DKIM signature fails whenever the message the receiver sees no longer matches what the sender signed. The most common causes are:
- Modification in transit — mailing lists, forwarders, and some gateways rewrite subjects, append footers, or re-encode the body, which breaks the body hash.
- Body hash mismatch — any change to the signed portion of the body changes
bh, so verification fails even if the key is correct. - Wrong or missing key — the selector points to a DNS record that is absent, expired, or holds the wrong public key.
For a fuller breakdown of the causes and fixes, see why DKIM fails, and use the free DKIM lookup tool to confirm a selector’s public key is published and well-formed.
Frequently Asked Questions
What is a DKIM signature?
A DKIM signature is a cryptographic signature added to an email’s headers in the DKIM-Signature field. The sender generates it with a private key over selected headers and a hash of the body. Receivers verify it against a public key in DNS, proving the message came from the domain and was not altered.
What does the b= tag in a DKIM signature mean?
The b= tag holds the actual signature: a base64-encoded value produced by signing a hash of the canonicalized signed headers with the sending domain’s private key. The receiver decodes it and verifies it against the public key fetched from DNS. If the signed headers changed in transit, the b= check fails.
Why does a DKIM signature fail after forwarding?
Forwarders and mailing lists often modify the message — appending footers, rewriting the subject, or re-encoding the body. Because DKIM signs the exact body and selected headers, any such change alters the computed hash so it no longer matches the signed bh or header hash. The signature then fails verification even though the original was valid.
What is the body hash (bh) in DKIM?
The bh= tag is a hash of the message body after canonicalization, computed with the algorithm named in a. On receipt, the verifier recomputes the body hash and compares it to bh. A mismatch means the body was altered in transit, so the signature is rejected before the cryptographic signature in b= is even checked.