DKIM glossary
What does the h= tag list in a DKIM signature?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
The h= tag is the colon-separated list of header fields a DKIM signature covers — From is mandatory. Any header not listed can be changed or added after signing without breaking the signature, which is why careful signers oversign critical headers. A minimal h= is a quiet security gap.
h= at a glance | |
|---|---|
| Tag | h (signed header fields) |
| Valid values | A colon-separated list of header field names, e.g. from:to:subject:date |
| Default | Required in the signature; the From field MUST be included. |
| Where it goes | In the DKIM-Signature header. |
How h= works
h= lists, colon-separated, exactly which header fields the signature covers — for example from:to:subject:date. Only the headers named here are protected by the signature, and From is mandatory and must always appear.
The subtle part is what's not listed. A header field left out of h= can be altered, or a fresh copy added, after signing without breaking the signature — because the hash never covered it. A stingy h= is therefore a quiet security gap: an attacker could inject or replace unsigned headers and the DKIM check would still pass.
Careful signers defend against this by oversigning: listing a critical header like From twice in h=. That extra slot means adding another From header after signing breaks the signature, blocking a header-injection trick. If you can choose what your signer covers, sign the headers that matter and oversign the ones an attacker would target.
Correct record vs common mistake
Correct
DKIM-Signature: ...; h=from:from:to:subject:date; ...From is signed and oversigned (listed twice), so adding a second From header after signing breaks the signature — closing a header-injection gap.
Common mistake
DKIM-Signature: ...; h=from; ...Only From is signed. Subject, To, and everything else can be changed or added after signing without breaking DKIM — a minimal h= that leaves real headers unprotected.
Troubleshooting h=
| Issue | Likely cause | Fix |
|---|---|---|
| Injected or duplicate headers still pass DKIM | Critical headers aren't oversigned in h= | Oversign From (list it twice) and cover the headers an attacker would target |
| Signature breaks when a header is added in transit | A signed header was duplicated or modified downstream | Sign only stable headers; avoid signing ones that relays legitimately add or rewrite |
| From not protected | h= omits From (invalid) or covers only trivial fields | Ensure From is in h=, then add To, Subject, and Date, and oversign From |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
Signers you don't control — an ESP or appliance with a minimal, non-oversigned h= — leave client mail open to header-injection tricks that still pass DKIM. Across a fleet you can't audit every platform's signing config by hand, so weak header coverage is an easy blind spot.
Trusted by MSPs
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
Enforce it — don't just monitor it
Header-injection risks hang on the From address — which is exactly the identity DMARC locks down. Palisade drives every client domain to enforced DMARC, so a message can't claim your From domain and land unless it authenticates and aligns.
Free 15-day trial · No credit card · Your own domain free forever (NFR)