Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →

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.

TagNamePurpose
vVersionDKIM version. Always 1.
aAlgorithmHash and signing algorithm, e.g. rsa-sha256 or ed25519-sha256.
dDomainThe signing domain — the identity DKIM authenticates.
sSelectorNames which public key to fetch from the domain’s DNS.
hSigned headersColon-separated list of header fields covered by the signature.
bhBody hashHash of the (canonicalized) message body.
bSignatureThe actual cryptographic signature, base64-encoded.
cCanonicalizationHow headers/body are normalized before hashing, e.g. relaxed/relaxed.
t / xTimestampst 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.

Rated 5/5 on G2 · Trusted since 2018

Trusted by 50,000+ domains

"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.
PJ

Peter J.

President · Small-Business (50 or fewer emp.)

"Helped us go beyond capacity"

AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.
VU

Verified User

Financial Services · Mid-Market (51-1000 emp.)

"Great service and great support"

AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.
GF

Greg F.

Mid-Market (51-1000 emp.)