What is double DKIM signing and when is it necessary for email authentication?
Published 2 May 2025
Updated 8 Oct 2026
11 min read
Summarize with
Updated on 8 Oct 2026: We clarified double DKIM signing for algorithm compatibility and tightened the DMARC and oversigning checks.
Double DKIM signing means one email message has two DKIM-Signature headers. The signatures can use two different domains, two different selectors under the same domain, or a mix of a sender-owned domain and an ESP-owned domain. It is not a special DMARC mode, and it does not make a message twice as authenticated.
Double DKIM signing is needed when a documented requirement calls for two signing identities or two algorithms on the same message. A provider can use its own signature for complaint processing, routing, abuse handling, or provider-level identification while it also signs with your domain for DMARC. If your ESP already signs with your visible From domain and DMARC passes, you usually do not need double signing for your authentication outcome.
Counter DKIM signing is not a standard DKIM term. Ask for the raw message headers and the exact DNS records behind the request. In practice, the phrase often means adding a second DKIM signature, changing the signing domain, or using DKIM oversigning.
What double DKIM signing means
DKIM (DomainKeys Identified Mail) adds a cryptographic signature, created with a private key, covering selected headers and a hash of the email body. The receiver looks up the public key in DNS, verifies the signature, and records whether that specific signature passed. Multiple signatures are allowed, and receivers evaluate each attempted signature separately. DKIM does not encrypt email or establish that the signing domain matches the visible From domain.
A message with two signatures is common when an ESP signs once with the customer's domain and once with the ESP's domain. The customer-domain signature matters for DMARC because it can match the visible From domain. The ESP-domain signature can support complaint processing, identify the provider as a signer, or associate the message with provider-level systems.
Abbreviated headers with two DKIM signaturestext
From: Sender <sender@brand.example> DKIM-Signature: v=1; a=rsa-sha256; d=brand.example; s=s1; h=from:to:subject:date:mime-version; bh=...; b=... DKIM-Signature: v=1; a=rsa-sha256; d=esp.example; s=s2; h=from:to:subject:date:mime-version; bh=...; b=...
Double DKIM signing flow: brand and ESP sign, then the receiver checks signatures and DMARC.
How receivers evaluate multiple DKIM signatures
RFC 6376 tells receivers to evaluate multiple DKIM signatures independently. Header order does not establish DKIM signature precedence, and a failed signature does not cancel a different signature that passes. A receiver can process signatures in any order and can limit how many it attempts to protect its resources.
- A passing provider-domain signature proves that signature, but it does not satisfy DMARC for an unrelated visible From domain.
- A passing sender-domain signature can satisfy DMARC even when another signature fails.
- Under relaxed alignment, the DKIM d= domain and visible From domain share the same Organizational Domain. Strict alignment requires identical domains.
- Read per-signature Authentication-Results added by your trusted receiving mail system, then compare them with the final DMARC result. RFC 8601 explains why untrusted upstream results are not reliable.
One aligned pass and one failed signaturetext
Authentication-Results: mx.receiver.example; dkim=pass header.d=brand.example header.s=s1; dkim=fail (bad signature) header.d=esp.example header.s=s2; dmarc=pass header.from=brand.example
RFC 9989, which replaced RFC 7489 in 2026, keeps the rule that DMARC passes when any validated DKIM signing domain has alignment with the Author Domain. RFC 9990 tells aggregate reporters to prioritize strict aligned passes, then relaxed aligned passes, other passing signatures, and failures. A report can contain several DKIM results for the same sending source, but it is not a complete inventory of every signature received.
A DKIM pass and a DMARC pass answer different questions. DKIM confirms that one signature verified. For the DKIM route, DMARC also checks whether the verified d= domain has alignment with the visible From domain. DMARC can also pass through SPF when the authenticated MAIL FROM domain has the required alignment.
When double signing is necessary
Double signing is necessary when one signature does not satisfy a documented identity or algorithm requirement. A marketing platform or ESP can sign with your domain for DMARC, then also sign with its own domain for a complaint program or provider workflow that depends on its signing identity. That second signature is primarily for the provider, not for your DMARC pass result.
Double signing can also be useful during a controlled migration when two systems add signatures to the same message. Key rotation usually works differently: old and new selectors remain published in DNS for an overlap period, while each new message receives one current signature. Keep old public keys available until messages signed with them have cleared your delivery queues and retry window. Plan any infrastructure migration and sending warmup separately from the number of signatures.
|
|
|
|---|---|---|
ESP plus brand | Provider-dependent | Brand DMARC and documented ESP operations |
RSA plus Ed25519 | Compatibility option | One sender signs with both algorithms |
Key rotation | Rarely | Most rotations overlap DNS keys but sign once |
Gateway signing | Sometimes | The final system signs after content changes |
Normal DMARC | No | One aligned DKIM pass is enough |
Common double signing scenarios
A gateway or mailing list can add its own signature after changing the message. That signature does not repair the original signature or satisfy DMARC for an unrelated From domain. When you control the outgoing path, add the sender-domain signature after the final content changes.
Dual signing with RSA and Ed25519
One sender can add two signatures using the same d= domain and different signing algorithms. RFC 8463 describes using rsa-sha256 together with ed25519-sha256 for backward compatibility. This is dual signing for algorithm compatibility and does not require two separate organizations.
Abbreviated dual algorithm signaturestext
DKIM-Signature: v=1; a=rsa-sha256; d=brand.example; s=rsa1; h=from:to:subject:date; bh=...; b=... DKIM-Signature: v=1; a=ed25519-sha256; d=brand.example; s=ed1; h=from:to:subject:date; bh=...; b=...
The RSA and Ed25519 keys need different selectors because each selector identifies one DKIM public key record. Publish the RSA key with k=rsa and the Ed25519 key with k=ed25519, then confirm that each s= value resolves to its matching key.
If an intended receiver does not support Ed25519, a valid RSA signature can still satisfy DMARC when its d= domain has the required alignment with the visible From domain. Retaining RSA during an Ed25519 rollout is a compatibility choice, not a universal requirement to sign every email twice.
When one DKIM signature is enough
If your ESP signs with your domain and that domain has alignment with the visible From domain under DMARC rules, one DKIM signature is enough for your authentication result. A second signature can still exist, but it is not needed to pass DMARC.
Do not treat the lack of double signing as a problem by itself. Investigate a missing valid signature, broken DNS, an unknown selector, body changes after signing, or a platform that signs only with its own domain when your domain needs to carry the aligned authentication result.
What matters for you
- Under relaxed DMARC alignment, the DKIM d= domain and visible From domain share the same Organizational Domain.
- The s= selector must lead to a valid public key in DNS.
- At least one aligned DKIM pass can satisfy DMARC.
What matters for the ESP
- The ESP can sign with its own d= domain for operational tracking.
- A complaint program can depend on a signing domain controlled by the provider.
- A provider signature can connect delivered mail to the platform's abuse records.
Double signing is not oversigning
Double DKIM signing and DKIM oversigning sound similar, but they solve different problems. Double signing means two DKIM-Signature headers on one message. Oversigning means listing a header field in h= more times than that field exists in the message, so adding another instance of that field breaks verification. It does not prevent an unchanged signed message from being resent.
The practical explanation of the second concept is under DKIM oversigning. For this topic, the key point is simple: oversigning changes what a signature covers, while double signing changes how many signatures are present.
Oversigning a single From header (abbreviated)text
DKIM-Signature: v=1; a=rsa-sha256; d=brand.example; s=s1; h=from:to:subject:date:from; bh=...; b=...
Do not approve DNS changes based only on the phrase counter signing. Ask for the exact selector, the signing domain, a sample raw header, and a clear reason the second signature is needed.
How to verify what is happening
The fastest way to settle a double signing question is to inspect a real delivered message. Look for every DKIM-Signature header, then compare each d= domain, s= selector and a= algorithm to DNS. If there are two DKIM-Signature headers, the email is double signed. Oversigning is present when h= lists a header field more times than that field actually appears in the message. A double-signed message can also use oversigning.
For selector-level DNS checks, use Suped's DKIM checker to confirm the DNS key exists and parses cleanly. For a wider authentication check across a domain, a domain health check gives a broader view of DKIM, SPF, DMARC, and related DNS health. A DNS key check does not verify a delivered message's cryptographic signature; use the trusted receiver's results for that.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
When an ESP asks for new DNS records, check whether the request is for a TXT public key or a CNAME delegation. Both are normal patterns. Look up the key at selector._domainkey.signing-domain using the message's s= and d= values, and confirm that it is the intended provider key. Publish only one DKIM public key record per selector hostname, with different selectors for independent keys. Two DNS records alone do not prove double signing; the delivered message headers prove it.
Typical DKIM DNS recordsdns
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIB..." vendor1._domainkey.example.com. CNAME vendor1.domainkey.esp.example.
Questions to ask your ESP
If the explanation is vague, move the conversation to concrete headers and DNS. A support answer that says double signing is unsupported is not enough. The useful answer states which domain signs, which selector is used, and which requirement fails without a second signature.
- Will you sign with the customer domain, the provider domain, or both domains?
- Which selector will appear in the s= tag, and what DNS hostname must exist?
- Does a complaint program require your provider domain to sign the message?
- Will a footer, link rewrite, or gateway change the message after either signature is added?
- Can you provide a sample raw header after the change is enabled?
The last question matters most. Raw headers show whether the platform is actually adding multiple DKIM signatures, whether the right signature passes, and whether the requested DNS records are in use.
How Suped tracks DKIM and DMARC results
Suped's DMARC reporting and email authentication platform connects DKIM results with DMARC outcomes for each sending source. The practical workflow is to determine whether a sender-domain signature passes and whether a selector or provider change introduced failures.
Suped's DMARC monitoring workflow groups reports by source, signing domain, selector, and result. That lets teams compare authentication before and after a provider migration or key change without treating every second signature as an error.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
That matters when an ESP says a second signature, new selector, or extra DNS record is required. Suped helps show whether the current signature fails, whether the d= domain lacks alignment, or whether SPF supplies the aligned DMARC pass instead. Compare those results with the provider's documented requirement to establish why it wants an extra signature.
Practical decision path
Use a simple decision path. First, confirm whether the message has one DKIM-Signature header or more than one. Next, identify the d= domain on each signature and verify its result. Then check whether at least one passing DKIM signature has alignment with the visible From domain for DMARC. Finally, ask which documented process needs any extra signature.
Double signing need level
Use this as a quick read on whether double DKIM signing is required.
Not needed
Low
One valid DKIM signature with the required domain alignment satisfies DMARC.
Useful
Medium
A controlled migration or algorithm transition uses two signatures.
Required
High
A documented workflow needs both signing identities or algorithms.
If the extra signature supports the ESP's own systems, that can be a valid provider requirement, but it is different from saying your DMARC setup needs two signatures. If the ESP signs only with your domain and the message passes DMARC, ask the provider to identify the specific complaint or internal process that also needs its domain.
Views from the trenches
Best practices
Check the d= domain first; it tells you whose DKIM identity each signature uses at receipt.
Keep your domain signature active when an ESP also signs with its own provider domain.
Ask for the exact selector and DNS record before changing a complaint feedback loop setup.
Common pitfalls
Treating two DKIM signatures as required for DMARC causes needless DNS changes and delays.
Confusing double signing with oversigning leads teams to fix the wrong header issue first.
Treating overlapping DNS keys during rotation as proof of double signing causes confusion.
Expert tips
Save raw headers from a real message before debating what an ESP actually signed for you.
Use separate selectors when provider ownership or key rotation boundaries need to stay clear.
Check algorithm needs as well as provider identity when deciding if a second signature is useful.
Expert view
Expert from Email Geeks says double signing is mainly for the provider when the sender's domain already signs and passes DMARC.
2024-07-11 - Email Geeks
Marketer view
Marketer from Email Geeks says using the sender's domain keeps DKIM identity consistent during ESP changes, while new infrastructure still needs warmup.
2024-07-11 - Email Geeks
