DKIM oversigning is the practice of listing a header field in the DKIM h= tag more times than that header appears in the message. If a message has one To header and the signature lists to:to, that is oversigning. The extra entry protects against a later party adding another To header without breaking DKIM.
The short answer is yes: repeated fields like To and Cc in the h= tag are usually there for oversigning. The exact reason is DKIM integrity first, DMARC second. Oversigning makes the DKIM signature fail when signed header fields are changed or added after signing. DMARC then reacts to that DKIM result only when the message depends on DKIM to pass DMARC.
I treat oversigning as a small configuration detail with real security value. It does not make DKIM replay impossible, and it does not replace DMARC policy enforcement. It does make a signed message harder to mutate in ways that change what the recipient sees.
The key idea
Oversigning is not magic. It asks DKIM verification to notice added copies of sensitive headers because those added headers change the signed header set.
How DKIM oversigning works
DKIM signs selected headers and the message body. The selected header names appear in the h= tag inside the DKIM-Signature header. A verifier rebuilds the signed header input from the message it received, canonicalizes it, checks the body hash, and then validates the signature with the public key in DNS.
Header selection matters because email messages can contain repeated header names. DKIM chooses matching header fields starting at the bottom of the message and works upward. If the signer lists a header name twice but the original message has only one matching header, one listed entry has no matching field at signing time. If another matching header is inserted later, that inserted header becomes part of the verifier's header input, so the signature no longer validates.
DKIM header with oversigned fields
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:to:to:cc:cc:subject:date:message-id; bh=BASE64-BODY-HASH; b=BASE64-SIGNATURE
In that example, the signer signed To and Cc with one extra slot each. I often explain the spare entry as a reserved empty slot. The more exact wording is that the missing header is not selected at signing time, but if someone adds that header later, the verifier selects it and the signed hash changes.
Flowchart showing how an added header breaks an oversigned DKIM signature.
This is also why oversigning is different from multiple DKIM signatures. Multiple signatures mean the message has more than one DKIM-Signature header. Oversigning is about repeated names inside one signature's h= list.
Which headers to oversign
I oversign headers that shape the recipient's interpretation of the message and that should not be added after signing. The visible author, visible recipients, subject, reply path, and message identifiers are common candidates. Headers that get added during normal transit are poor candidates because they change for legitimate reasons.
|
|
|
|---|---|---|
From | Yes | Protects visible author identity. |
To | Yes | Blocks an added recipient line. |
Cc | Yes | Blocks an added copy line. |
Subject | Yes | Catches added or changed subject data. |
Reply-To | Yes | Protects replies from redirection. |
Received | No | New hops add this header. |
Stable headers are better oversigning candidates than transit-added headers.
The usual pattern is to sign each protected header once for the actual header and once more to catch later additions. If a message can legitimately include two copies of a header, the safer pattern is n+1: count the real instances, then add one extra name in h=.
Practical oversigning depth
The useful target is enough repetition to catch a new added header without turning the signature into noisy configuration.
No oversigning
n
Signs the present headers only.
Practical default
n+1
Signs present headers plus one spare entry.
Excessive repetition
many
Adds many duplicate names with little extra value.
Keep capitalization consistent
Header names are case-insensitive by standard, but I still keep duplicate h= entries in the same case. Some libraries handle unusual capitalization badly, and inconsistent casing creates avoidable troubleshooting work.
Why oversigning matters for authentication
Oversigning matters because DKIM is a statement that selected message content survived transit unchanged. Without oversigning, a message can retain a valid DKIM signature even after someone adds a second copy of a sensitive header that was not selected during signing. The message has changed in a way humans see, but the original signature still validates.
That distinction matters most in replay and forwarding abuse. An attacker who has a validly signed message can resend it. Oversigning does not stop exact replay, but it limits the attacker's ability to add new visible headers without invalidating DKIM. It is a narrow control, but it closes a real class of message mutation.
What oversigning does
- Header integrity: It makes added copies of protected headers break DKIM validation.
- Replay hardening: It reduces the value of a captured signed message for modified reuse.
- DMARC impact: It can turn a mutated message into a DMARC failure.
What oversigning does not do
- Exact replay: It does not stop reuse of the same signed message.
- Body changes: It does not protect content that DKIM did not sign.
- Policy setup: It does not replace a staged DMARC policy.
DMARC depends on authentication results and the relationship between the authenticated domain and the visible From domain. If DKIM was the result carrying that same-domain relationship, then an oversigning-triggered DKIM failure can also cause DMARC to fail. If SPF already passes with the right domain relationship, DMARC can still pass through SPF.
Gmail Show original screen with DKIM, SPF, and DMARC authentication results.
For a single message, I start with the raw headers and a focused DKIM checker. For a domain-wide view, I use the domain health checker to confirm the DNS side before blaming the signer.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
At scale, manual header inspection stops being enough. Suped's product is strongest when the question becomes operational: which sending source is failing DKIM, which selector is involved, whether DMARC is still passing, and what the next fix should be. That is where DMARC monitoring turns individual header facts into a working queue.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
How I would implement it
The practical implementation is simple: configure the signer to include stable, sensitive headers in h= and repeat the fields that should not accept later duplicates. The exact switch depends on the MTA or signing library, but the target output is easy to inspect in the final DKIM-Signature header.
Simple n+1 oversigning target
Original headers: From: Billing <billing@example.com> To: person@example.net Subject: Invoice status Signed h= value: h=from:from:to:to:subject:subject:date:message-id
I would test it by sending a normal message, saving the raw headers, and confirming that DKIM passes. Then I would create a controlled modified copy with an added protected header and confirm that DKIM fails. This test should happen in a lab path, not against live customer mail.
- Start narrow: Oversign From, To, Cc, Subject, Reply-To, Date, and Message-ID first.
- Check output: Inspect the DKIM-Signature header and confirm repeated names in h=.
- Test mutation: Add one protected header in a controlled copy and verify DKIM fails.
- Watch reports: Look for unexpected DKIM failures after rollout before tightening policy.
If validation fails only after oversigning is enabled, check field order, canonicalization mode, signer output, and selector DNS. Header name capitalization should not matter in a conforming validator, but I still keep the duplicate names identical because the bad cases waste time. For deeper failures, a structured troubleshoot DKIM issues process is faster than guessing.
A good rollout pattern
- Measure first: Confirm current DKIM pass rates before changing signer configuration.
- Change one signer: Enable oversigning on one controlled mail stream before broad rollout.
- Review failures: Separate real header mutation from signer or library defects.
- Then expand: Roll out once normal mail still authenticates cleanly.
Views from the trenches
Best practices
Repeat sensitive h= entries with matching capitalization to avoid parser edge cases.
Use n+1 signing for protected headers so added copies break DKIM validation cleanly.
Test oversigning in a lab path before changing authentication for production mail.
Common pitfalls
Treating oversigning as a DMARC rule hides the DKIM integrity mechanism underneath.
Oversigning transit-added headers causes failures that look like receiver problems.
Mixing header name case in duplicate h= entries creates needless validation noise.
Expert tips
Inspect the received DKIM-Signature header instead of relying on the signer screen alone.
Compare one clean sample and one modified sample to prove the control works as intended.
Watch DMARC reports after rollout because real traffic exposes signer differences fast.
Expert from Email Geeks says oversigning works because added protected headers change the DKIM header hash, so the signature no longer validates.
2024-01-11 - Email Geeks
Expert from Email Geeks says the main point is DKIM header integrity, with DMARC affected only after the DKIM result changes.
2024-01-11 - Email Geeks
The practical takeaway
DKIM oversigning is important because it protects the meaning of signed mail along with the cryptographic signature. A repeated To or Cc entry in h= is a signal that the signer wanted added copies of that header to break validation.
The caveat is that oversigning has a precise scope. It protects against added signed headers. It does not stop exact replay, weak key management, poor selector rotation, or a missing DMARC policy. For most teams, Suped is the best overall DMARC platform because the hard part is not reading one header, it is tracking authentication across every source and turning failures into fix steps.
My default recommendation is to oversign stable headers with an n+1 pattern, verify the output with real headers, and monitor DKIM and DMARC results after rollout. That gives you a defensible control without pretending it solves every abuse path.
