What is DKIM oversigning, how does it work, and why is it important for email authentication?
Updated on 20 Oct 2026: We clarified DKIM oversigning for absent headers and added checks for failures after rollout.
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 indicate oversigning only when their entries outnumber matching headers in the message. Standard DKIM already detects changes to selected existing fields, subject to canonicalization. Oversigning adds protection against new copies of those field names. DMARC reacts to the resulting DKIM failure only when no other qualifying authentication result remains.
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. Without the extra entry, a duplicate prepended above the signed original can remain outside the signature because the verifier still selects the bottommost instance.
Illustrative DKIM header with oversigned fields
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:from:to:to:cc:cc:subject:date:message-id; bh=BASE64-BODY-HASH; b=BASE64-SIGNATURE
Assuming the message has one From, one To, and one Cc header, the example oversigns each of those fields with one extra entry. No header is selected for that entry at signing time. If someone adds that header later, the verifier selects the new field and the signed hash changes. The body hash and signature values shown are placeholders, not a usable signature.
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 that exceed the number of matching message headers.
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 address, and message identifiers are common candidates. DKIM requires the From header to be signed; oversigning it is an additional safeguard. Headers added during normal transit are poor candidates because they change for legitimate reasons.
|
|
|
|---|---|---|
From | Yes | Detects additional From headers; signing the original From is mandatory. |
To | Yes | Blocks an added recipient line. |
Cc | Yes | Blocks an added copy line. |
Subject | Yes | Oversigning detects added subjects; signing detects changes to the original. |
Reply-To | Yes | Detects added reply addresses, including when Reply-To was originally absent. |
Date / Message-ID | Yes | Protects date and message identity against added copies. |
MIME-Version / Content-Type / Content-Transfer-Encoding | When stable | Protects content interpretation; sign after final MIME formatting. |
Received | No | New hops add this header. |
Return-Path | No | Normal delivery adds or replaces the envelope return path. |
Stable headers are better oversigning candidates than transit-added headers.
Use the n+1 pattern: count the actual instances of a protected field, then add one extra name in h=. For one existing header, list its name twice. If Reply-To is absent, listing reply-to once protects its absence: adding that field later breaks the signature. Do not insert a blank Reply-To header. One extra entry is sufficient to detect any number of added instances.
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
Names in the h= list are matched without regard to case, so From and from select the same field. Keeping repeated names in the same case makes manual inspection easier. This matching rule does not allow a gateway to change an actual message header's capitalization under simple header canonicalization, which preserves the original header bytes.
Why oversigning matters for authentication
DKIM verifies selected message content after canonicalization. Without oversigning, a message can retain a valid DKIM signature after someone prepends a second copy of a sensitive header above the signed original. Email software can display or process that duplicate differently even though 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
- It makes added copies of protected headers break DKIM validation.
- It reduces the value of a captured signed message for modified reuse.
- It can turn a mutated message into a DMARC failure.
What oversigning does not do
- It does not stop reuse of the same signed message.
- It does not protect appended content beyond an l= body-length limit.
- It does not replace staged DMARC enforcement.
Under RFC 9989, DMARC passes when SPF or DKIM supplies an authenticated identifier with the required domain relationship to the visible From domain, called the Author Domain. An oversigning-triggered DKIM failure causes DMARC to fail only if no other qualifying result remains. SPF or another valid DKIM signature with the required domain relationship can still produce a DMARC pass. The receiver then applies its handling policy; a DKIM failure alone does not require rejection.
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, inspect the raw DKIM-Signature header and compare its h= entries with the actual header counts. Suped's DKIM checker checks the selector's DNS key record. The domain health checker checks broader domain configuration. Neither DNS check confirms oversigning, because the protected header list is in the message, not the public key record.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Suped's DMARC monitoring groups aggregate reports by sending source and authentication result, so teams can compare DKIM failures before and after a signer change. Use selector details when supplied by the reporting receiver to identify the affected mail stream. RFC 9990 defines aggregate reporting, which does not include the full message or its h= list. A raw message sample is still needed to diagnose header insertion or prove oversigning.
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.
Use oversigning within a broader replay-risk plan. Full-body signing limits modified reuse. Selector isolation and key revocation help contain replay of an unchanged message, but revocation also affects legitimate mail signed with that key. None of these controls makes DKIM per-recipient authorization.
- Avoid the optional l= body-length tag unless a measured compatibility need outweighs the risk of appended content.
- Sign and oversign the headers a recipient uses to interpret the message.
- The optional t= and x= tags record signing and expiration times, but receiver handling of an expired signature is discretionary.
- 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 include one extra entry for fields that should not accept later copies. The exact setting depends on the MTA or signing library. Oversigning is configured in the sending system; it needs no separate DNS tag or public key change. If a hosted sender manages the signing configuration, ask its operator whether oversigning is supported. Inspect the final DKIM-Signature header to confirm the result.
Simple n+1 oversigning target
Original headers: From: Billing <billing@example.com> To: person@example.net Subject: Invoice status Date: Wed, 21 Oct 2026 10:00:00 +0000 Message-ID: <invoice-001@example.com> (No Reply-To header) Signed h= value: h=from:from:to:to:subject:subject:date:date: message-id:message-id:reply-to
Test the change by sending a normal message, saving the complete raw message, and confirming that its DKIM signature passes. Then add a protected header to a controlled copy and verify the original signature again. Do not send the copy through a signer that replaces the original signature. Use a lab verifier that reports signature validation separately from any rejection of malformed duplicate headers.
- Start with stable fields that your mail flow preserves, including From, To, Cc, Subject, Reply-To, Date, and Message-ID.
- Inspect the final DKIM-Signature header and confirm each protected name occurs one more time in h= than in the message.
- Add a protected header to a controlled copy and confirm the original DKIM signature fails verification.
- Check DKIM results separately from the overall DMARC result, then review unexpected failures before expanding rollout.
A good rollout pattern
- Confirm current DKIM pass rates before changing signer configuration.
- Enable oversigning on one controlled mail stream before broad rollout.
- Separate real header mutation from signer or library defects.
- Roll out once normal mail still authenticates cleanly.
How to troubleshoot oversigning failures
If validation fails after oversigning is enabled, save raw messages immediately after signing and at receipt. Compare protected header counts and values, then inspect the receiving system's Authentication-Results header. Trust results added by the receiving system, rather than an arbitrary result supplied with the message, as explained in RFC 8601.
|
|
|
|---|---|---|
Original passes; an added protected header makes the copy fail | The original signature was preserved and the verifier checked it. | This is the expected result of oversigning. |
Normal delivery fails after a protected header is added | A gateway or mailing list added a field such as Reply-To after signing. | Move controlled header additions before signing; test forwarding and mailing list paths. |
Body hash mismatch | A footer or MIME change altered the body after signing. | Complete body changes before signing; changing the oversigned header list will not fix them. |
Public key cannot be retrieved | The d= domain and s= selector identify the expected DNS record. | Correct the selector or DNS key record; this is separate from oversigning. |
Separate header insertion from body changes and key lookup problems.
Relaxed header canonicalization tolerates defined whitespace and header-name case changes. It does not permit adding an oversigned header. Simple header canonicalization preserves header bytes, so changing a real header's case can break its signature even though h= matching is case-insensitive. These are separate rules in RFC 6376.
If the failure remains unexplained, troubleshoot DKIM issues by comparing the saved message with the received copy before changing the signing policy.
DKIM oversigning deployment checks
Best practices
Count each protected header and add one extra h= entry to detect later header insertion.
Include absent Reply-To headers in h= once to prevent their insertion after signing.
Test unchanged and modified messages through normal delivery paths before production rollout.
Common pitfalls
Repeated h= names do not prove oversigning unless they outnumber matching message headers.
Transit-added headers such as Received cause expected additions to invalidate the signature.
Changing a real header's case can break simple canonicalization, even with valid h= matching.
Expert tips
Save raw messages before and after transit so added headers can be traced to a specific hop.
Compare DKIM results for each signature because another valid signature can preserve DMARC.
Use aggregate reports to spot failing sources, then inspect message headers for the h= list.
Frequently asked questions
No. DMARC does not require DKIM oversigning. DMARC checks whether SPF or DKIM passes with the required relationship to the visible From domain. Oversigning protects the DKIM result from later header additions.
If the message has one To header, to:to oversigns it: one entry selects the original, and the extra entry detects later additions. If two To headers already exist, two entries alone do not prove oversigning. Compare the h= count with the actual message headers.
It stops modified replay that depends on adding protected headers. It does not stop exact reuse of the same signed message or delivery to a different SMTP envelope recipient.
No. Oversign stable headers that should not be added after signing. Avoid headers that normal mail transfer adds or modifies, such as Received.
Changing the case of names in h= is not needed: field-name matching is case-insensitive. However, changing an actual signed message header's capitalization after signing can break simple header canonicalization. Relaxed header canonicalization normalizes header-name case. Editing h= after signing also changes signed signature metadata.
Oversigning and full-body signing do not stop an unchanged message from being replayed. Use separate keys and selectors for mail streams so a compromised stream can be revoked without affecting every sender. Monitor unexpected traffic and investigate reuse. The optional x= tag limits lifetime only when a receiver honors expiration; revoking a key also invalidates legitimate signatures that use it.
