What is DKIM oversigning, how does it work, and why is it important for email authentication?
Updated on 12 Aug 2026: We clarified DKIM's n+1 header logic and added practical controls for exact replay risk.
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.
Repeated fields such as To and Cc in the h= tag usually indicate oversigning. Standard DKIM already detects changes to selected existing fields. Oversigning adds protection against new copies of those field names. DMARC reacts to the resulting DKIM failure only when the message depends on DKIM to pass DMARC.
Oversigning is a small configuration detail with concrete security value. It does not make DKIM replay impossible, and it does not replace DMARC policy enforcement. It makes a signed message harder to mutate in ways that change what the recipient sees.
The key idea
RFC 6376 permits, but does not require, a signer to list a field more times than it exists. Each extra name asserts that no additional copy should appear after signing, so a later addition changes the verifier's signed header input.
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, applies the chosen canonicalization, checks the body hash, and validates the signature with the public key in DNS.
RFC 6376 defines bottom-up selection when a field name occurs more than once. If the signer lists a header name twice but the original message has only one matching header, the second listed entry contributes no field at signing time. If another matching header is inserted later, the verifier selects it, the signed input changes, and 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. The spare entry is often described as an empty slot. More precisely, no header is selected for it at signing time. If someone adds that header later, the verifier selects the new field and the signed hash changes.
Flowchart showing how an added header breaks an oversigned DKIM signature.
This is also why oversigning differs from multiple DKIM signatures. Multiple signatures mean the message has more than one DKIM-Signature header. Oversigning concerns repeated names inside one signature's h= list.
Which headers to oversign
Oversign headers that shape the recipient's interpretation of the message and should not be added after signing. The visible author, visible recipients, subject, reply path, and message identifiers are common candidates. Headers 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, use the n+1 pattern: count the real instances, then add one extra name in h=. One extra entry is sufficient to prevent any number of later additions from validating.
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.
Header name case
DKIM verification must compare header names without regard to case, so From and from are equivalent. Keeping repeated h= entries in the same case still makes manual inspection and configuration comparison easier.
Why oversigning matters for authentication
Oversigning matters because DKIM states that selected message content survived transit unchanged. Without oversigning, a message can retain a valid DKIM signature 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 closes a specific message-mutation path.
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.
- Partial body signing: It does not protect appended content beyond an l= body-length limit.
- Policy setup: It does not replace staged DMARC enforcement.
Under RFC 9989, DMARC passes when SPF or DKIM supplies an authenticated identifier with the required relationship to the Author Domain. If DKIM carried that relationship, an oversigning-triggered DKIM failure can cause DMARC to fail. If SPF passes with the required domain relationship, DMARC can still pass through SPF.
Oversigning does not guarantee better inbox placement. Its deliverability value is risk reduction: it prevents a valid DKIM signature from continuing to validate after protected header names are added. A bad signer configuration can instead create avoidable DKIM failures, which is why controlled testing matters.
Gmail Show original screen with DKIM, SPF, and DMARC authentication results.
For a single message, start with the raw headers and a focused DKIM checker. For a domain-wide view, 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 turns DMARC aggregate reports into an operational queue showing which sending source is failing DKIM, which selector is involved, whether DMARC still passes, and what to investigate next. DMARC monitoring connects individual header evidence with domain-wide authentication results.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
What oversigning cannot prevent
DKIM authenticates signed message content, not the SMTP delivery path. The envelope sender and envelope recipient are outside the DKIM header hash. A signed To field therefore does not restrict the mailbox used in the SMTP RCPT TO command. An unchanged signed message can be delivered to a different envelope recipient and still verify.
Oversigning should sit inside a broader replay-risk plan. These controls reduce what a captured signature can be used for, but none turns DKIM into per-recipient authorization.
- Sign the full body: Avoid the optional l= body-length tag unless a measured compatibility need outweighs the risk of appended content.
- Cover stable visible fields: Sign and oversign the headers a recipient uses to interpret the message.
- Set time metadata carefully: The optional t= and x= tags record signing and expiration times, but receiver handling of an expired signature is discretionary.
- Rotate and monitor: Use separate selectors for mail streams, retain the ability to revoke a key, and investigate sudden volume or reputation changes.
Expiration is not a complete replay control
RFC 6376 allows a verifier to treat a signature as invalid after its x= time, but does not require that outcome. The standard also says signature expiration is not intended as a standalone anti-replay defense.
How to implement DKIM oversigning
Configure the signer to include stable, sensitive headers in h= and repeat the fields that should not accept later duplicates. The exact setting depends on the MTA or signing library, but the target output is easy to inspect in the final DKIM-Signature header. Oversigning changes signature metadata, not the rendered email, and repeated names add only a small amount of header data.
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
Test the change by sending a normal message, saving the raw headers, and confirming that DKIM passes. Then create a controlled modified copy with an added protected header and confirm that DKIM fails. Run this test 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 does not affect a conforming validator, so case-only differences point to an implementation defect or a separate configuration problem. 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
DKIM oversigning recommendations
DKIM oversigning protects the meaning of signed mail along with the cryptographic signature. A repeated To or Cc entry in h= signals that the signer wanted added copies of that header to break validation.
Oversigning has a precise scope. It protects against added copies of named headers. It does not stop exact replay, weak key management, poor selector rotation, or a missing DMARC policy. Suped's product helps with the operational part by organizing DMARC aggregate data around sending sources, selectors, and authentication failures that need action.
Use an n+1 pattern for stable protected headers, verify the output with received headers, and monitor DKIM and DMARC results after rollout. This creates a defensible control without treating it as a solution for every replay path.
