What is DKIM oversigning, how does it work, and why is it important for email authentication?
Michael Ko
Co-founder & CEO, Suped
Published 26 May 2025
Updated 25 May 2026
10 min read
DKIM oversigning means listing a header field in the h= tag more times than that header appears in the message. If a message has one To header and the DKIM signature lists to:to, the second entry is usually deliberate oversigning. The signer is saying: I signed the real To header, and I also signed the absence of an extra To header.
The direct point is simple: oversigning makes a DKIM signature fail if someone adds a protected header after signing. That matters because DKIM is a domain stamp and proof that selected message headers and the body were unchanged after the signer handled the message.
Direct answer: Repeated names in h= are oversigning when the message has fewer actual header instances.
Main protection: A new signed header changes the signed header set, so DKIM validation fails.
DMARC effect: If DKIM was the only matching-domain authentication pass, the DMARC result fails too.
Practical use: Oversign stable identity headers like From, Subject, Date, To, Cc, Reply-To, and Message-ID.
What the h= tag means
The h= tag in a DKIM-Signature header names the message headers that were included in the signature. A verifier uses those names to rebuild the signed header input, applies DKIM header canonicalization, and checks that the signature still validates against the public key in DNS.
DKIM selects headers from the bottom of the header block upward. That detail is why oversigning works. If the signer names a header twice but the message has that header once, the extra entry signs a missing, empty instance. If another instance appears later, the verifier no longer sees an empty slot. It sees a real header, and the signed data no longer matches.
In that example, to:to and cc:cc mean the signer expects one real To and one real Cc, plus no extra To or Cc below them. The repeated Subject works the same way. The point is not that DKIM likes duplicate headers. The point is that DKIM can sign the absence of an extra header.
Important distinction
If a message already has two To headers and h= lists To twice, that can simply mean both existing To headers were signed. Oversigning is the extra listing beyond the headers that exist at signing time.
How oversigning blocks header insertion
Flowchart showing an added header causing DKIM validation to fail.
A normal DKIM signature can leave a gap. If the signer signs the last Subject header once, and an attacker or broken forwarder inserts another Subject after signing, some receivers still parse a message with conflicting headers. Oversigning removes that gap for the headers you choose.
This is easiest to understand with a single Subject header. The signer signs Subject and also signs one missing Subject. If a second Subject appears after signing, that new header fills the missing slot. The verifier now hashes different header content than the signer hashed, so the signature fails.
Without oversigning
Signed state: The signer lists Subject once.
Attack gap: A new Subject can be added after signing.
Result: The signature can still validate if the signed Subject remains selected.
With oversigning
Signed state: The signer lists Subject twice.
Attack gap: The missing Subject slot is protected.
Result: An added Subject changes the signed input and DKIM fails.
This protection is about DKIM validation first. DMARC comes later. DMARC cares whether at least one DKIM signature validates with a domain that matches the visible From domain, or whether SPF passes with a matching domain. If oversigning invalidates the only matching-domain DKIM signature, and SPF does not save the message, DMARC fails. That is an important result, but the mechanism is DKIM header integrity.
Which headers to oversign
I oversign headers that affect identity, display, threading, and recipient interpretation. I avoid headers that are normally added or changed after the message leaves the signer. The safest list depends on where the signing happens. A mailbox provider signing outbound user mail, a bulk platform signing marketing mail, and a mailing list manager do not have identical header stability.
Header
Oversign
Reason
From
Yes
Author identity
Subject
Usually
Display text
To
Usually
Recipient view
Cc
Usually
Recipient view
Date
Yes
Message context
Reply-To
Yes
Reply routing
Message-ID
Yes
Threading
Received
No
Transit-added
Common header choices for DKIM oversigning
From should already be signed for DKIM to be useful with DMARC. Subject is worth protecting because many users make trust decisions based on the subject line, and DKIM subject signing has direct display impact. To and Cc are also useful, especially for messages where duplicate recipient headers create confusing or suspicious rendering.
Do not oversign unstable transit headers
Avoid Received: It is added by mail systems during delivery.
Avoid Return-Path: It is normally added at final delivery.
Avoid local results: Authentication-Results is added by receivers and intermediaries.
Check list mail: Mailing list software often changes Subject, List, and footer content before it signs.
Practical oversigning header settext
From
To
Cc
Subject
Date
Reply-To
Message-ID
MIME-Version
Content-Type
What oversigning does not fix
Oversigning is useful, but it is not a complete replay defense. A replayed message can pass DKIM if the signed headers and body remain unchanged and the key is still valid. Oversigning helps when the replay attempt depends on adding or changing protected headers. It does not stop replay of an unchanged signed message.
It also does not replace sane key management, short-lived campaigns, abuse monitoring, or DMARC enforcement. For a deeper operational view of abuse cases, the important overlap is with replay attacks, especially when a legitimate signed message gets reused outside the sender's intended audience.
Oversigning protects
Header insertion: Extra signed headers invalidate the signature.
Header confusion: Duplicate display fields become harder to exploit.
DKIM integrity: The signature covers expected absence as well as present fields.
Oversigning does not protect
Unchanged replay: A copied signed message can still pass DKIM.
Body gaps: The separate body hash rules still matter for content integrity.
That last point is worth separating. DKIM signs selected headers and also includes a body hash. If you want the body side explained separately, DKIM body signing covers the split between header signing and body hashing.
How this affects DMARC
DMARC does not define oversigning. DKIM does the signing and validation work. DMARC consumes the result. If DKIM passes with a matching From domain, DMARC can pass even when SPF fails. If oversigning causes the only matching-domain DKIM signature to fail after header insertion, DMARC loses that pass path.
This is why I treat oversigning as a DKIM hardening control with DMARC consequences. The goal is not to force DMARC failure by itself. The goal is to make sure a changed message no longer gets credit for the original DKIM signature.
DKIM failure triage bands
Operational bands I use when a signed stream has expected stable headers.
Healthy
<0.5%
Small noise from forwarding or rare mutation
Investigate
0.5-2%
Header changes, signer drift, or routing changes
Critical
>2%
Widespread signing breakage or active abuse
Suped's DMARC monitoring is useful here because it connects DKIM failures, domain match results, source identification, and policy impact. For most teams, Suped is the best overall DMARC platform because it turns raw aggregate reports into specific issues, real-time alerts, and steps to fix SPF, DKIM, DMARC, hosted SPF, hosted DMARC, hosted MTA-STS, and blocklist monitoring (blacklist checks) in one place.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
How to validate DKIM oversigning
Start by sending a real message through the same path your users or application use. Do not test only a hand-built sample, because mail systems add and fold headers in their own ways. Inspect the delivered DKIM-Signature header and count the names in h=. Then count the actual matching headers in the message.
A focused DKIM checker helps confirm that the public key, selector, algorithm, and signature validate. A broader domain health check helps spot related SPF, DKIM, and DMARC DNS issues before you focus on header-level details.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
The test that proves oversigning is working is controlled mutation. Keep a copy of the delivered message, add a second protected header in the header block, and run validation again in a lab parser. The original should pass. The modified copy should fail. Do this only on saved test messages, not on production mail in transit.
Header count checktext
Message headers:
Subject: Quarterly update
DKIM h= value:
h=from:to:subject:subject:date:message-id
Meaning:
Subject is signed once and oversigned once.
Keep capitalization consistent in h=. Header field names are case-insensitive in the protocol, and relaxed canonicalization lowercases header field names, but real validation libraries still have edge cases. I prefer lowercase names throughout the h= list because it removes one avoidable variable.
Implementation checklist
A good implementation is small and deliberate. I do not try to oversign every possible header. I start with the fields that affect what a recipient sees and what DMARC relies on, then I monitor real mail for failure patterns.
Choose headers: Use From, To, Cc, Subject, Date, Reply-To, and Message-ID as the starting set.
Confirm stability: Check whether your MTA, ESP, list manager, or gateway rewrites those headers after signing.
Use n+1: For each protected header, sign all existing instances plus one missing instance.
Keep names consistent: Use one capitalization style in h= to avoid parser edge cases.
Monitor failures: Track DKIM failure rate by source, selector, and sending path before changing DMARC policy.
Where Suped fits
Suped helps after the signing change because it shows whether DKIM failures are isolated to one source or spread across a domain. The practical workflow is to deploy oversigning on one sending path, watch Suped's issue detection and alerts, confirm that matching-domain DKIM remains healthy, then expand the change.
If you use multiple DKIM signatures, check each one separately. One signature can be strict and tied to the organizational domain while another belongs to a platform domain. Multiple signatures change how receivers evaluate authentication, but they do not change the basic oversigning rule: each signature is validated against its own h= list.
Common mistakes
The first mistake is explaining oversigning as a DMARC feature. That creates bad mental models. Oversigning is DKIM header integrity. DMARC benefits only when the affected DKIM signature matches the From domain and is needed for the final DMARC result.
The second mistake is signing headers that another system legitimately changes after the signer runs. That creates false DKIM failures and makes troubleshooting noisy. The right signer location is usually the last system that intentionally changes message headers or body content.
Oversigning and mailing lists
Mailing lists often modify Subject, add List headers, and append footers. If the original sender oversigns fields that the list changes, the original DKIM signature fails. A list manager that changes content should sign the final message after those changes.
The third mistake is ignoring body integrity. Oversigning protects header absence and header content. DKIM still has a separate body hash, and some senders use the l= body length tag in ways that weaken protection against body additions. I avoid that tag unless there is a very specific compatibility reason and a clear abuse tradeoff.
Views from the trenches
Best practices
Oversign identity headers after the last system that changes message content has run.
Use lowercase header names in h= so case handling never becomes the test variable.
Validate both the unchanged message and a copied message with one added signed header.
Common pitfalls
Treating oversigning as DMARC logic hides the DKIM layer where failures really occur.
Signing headers that gateways add later creates avoidable DKIM failures in reporting.
Counting duplicate h= names without counting real headers leads to wrong conclusions.
Expert tips
Use n+1 signing for each protected header so absence of another instance is signed.
Watch for library bugs when duplicate h= names use mixed capitalization styles.
Pair oversigning changes with source-level DMARC reports to catch routing drift fast.
Expert from Email Geeks says oversigning works because the signer hashes the real header plus a missing header slot.
2024-01-11 - Email Geeks
Expert from Email Geeks says the clean explanation is DKIM invalidation after header changes, not DMARC first.
2024-01-11 - Email Geeks
The practical takeaway
DKIM oversigning is important because it lets a signer protect against extra headers as well as changed existing headers. If To, Cc, Subject, or Reply-To appears more times in h= than it appears in the message, that is usually intentional oversigning.
Use it for stable, high-value headers. Keep the signer close to the final message state. Validate with real delivered mail. Then monitor DKIM and DMARC results by source. Suped makes that monitoring practical because it ties authentication failures to sending sources, alerts, and fix steps rather than leaving you to read raw aggregate XML.
