Suped

What is double DKIM signing and when is it necessary for email authentication?

Published 2 May 2025
Updated 1 Aug 2026
10 min read
Summarize with
Two DKIM signatures attached to one email message.
Updated on 1 Aug 2026: We updated this guide for RFC 9989 and RFC 9990, with clearer guidance on signature evaluation, alignment, key rotation, and selectors.
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.
The direct answer: double DKIM signing is necessary only when two parties need separate DKIM identities 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 adds a cryptographic signature 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 signature separately.
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, prove the provider's handling path, or associate the message with provider-level systems.
Example email with two DKIM signaturestext
DKIM-Signature: v=1; a=rsa-sha256; d=brand.example; s=s1; h=from:to:subject:date:mime-version; b=... DKIM-Signature: v=1; a=rsa-sha256; d=esp.example; s=s2; h=from:to:subject:date:mime-version; b=...
Flowchart showing brand and ESP DKIM signatures checked by the receiver.
Flowchart showing brand and ESP DKIM signatures checked by the receiver.

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.
  1. A passing provider-domain signature proves that signature, but it does not satisfy DMARC for an unrelated visible From domain.
  2. A passing sender-domain signature can satisfy DMARC even when another signature fails.
  3. Under relaxed alignment, the DKIM d= domain and visible From domain share the same Organizational Domain. Strict alignment requires identical domains.
  4. The Authentication-Results header should be read per signature, then checked against the final DMARC result.
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 therefore contain several DKIM results for the same message source.
A DKIM pass and a DMARC pass answer different questions. DKIM confirms that one signature verified. DMARC also checks whether the verified d= domain has alignment with the visible From domain.

When double signing is necessary

Double signing is necessary when one valid signature does not satisfy every party's documented 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 genuinely 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. Plan any infrastructure migration and sending warmup separately from the number of signatures.

Scenario

Need

Why

ESP plus brand
Often
Brand DMARC and documented ESP operations
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
  1. A second signature is required when a provider documents a workflow that needs its DKIM domain while your domain still needs to pass DMARC.
  2. A second signature is useful when a controlled migration genuinely produces both signatures on delivered mail.
  3. A second signature is unneeded when your visible From domain already has an aligned DKIM pass and DMARC reports show clean authentication.
  4. Two DNS records alone do not prove double signing. The delivered message headers prove it.

When it is not necessary

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
  1. Under relaxed DMARC alignment, the DKIM d= domain and visible From domain share the same Organizational Domain.
  2. The s= selector must lead to a valid public key in DNS.
  3. At least one aligned DKIM pass can satisfy DMARC.
What matters for the ESP
  1. The ESP can sign with its own d= domain for operational tracking.
  2. A complaint program can depend on a signing domain controlled by the provider.
  3. 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 more times than it appears so a replayed message cannot easily gain a new unsigned header without breaking verification.
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 the From headertext
DKIM-Signature: v=1; a=rsa-sha256; d=brand.example; s=s1; h=from:to:subject:date:from; 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 and s= selector to DNS. If there are two DKIM-Signature headers, the email is double signed. If there is one signature but the h= tag repeats a header field, that is oversigning.
For selector-level checks, use the 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.

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. Confirm that the requested hostname is a new selector, that it points to the intended provider key, and that the selector appears in actual sent mail.
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.
  1. Will you sign with the customer domain, the provider domain, or both domains?
  2. Which selector will appear in the s= tag, and what DNS hostname must exist?
  3. Does a complaint program require your provider domain to sign the message?
  4. Will a footer, link rewrite, or gateway change the message after either signature is added?
  5. 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 fits into the workflow

Suped's product connects DKIM results with DMARC outcomes, sending sources, provider changes, and DNS ownership. 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, whether SPF supplies the aligned DMARC pass instead, or whether the request supports a provider-only process.

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 sender-domain DKIM pass satisfies DMARC.
Useful
Medium
A controlled migration or gateway has overlapping signing paths.
Required
High
Two parties need distinct DKIM identities on the same message.
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 judging a FBL or CFBL setup request.
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.
If your domain signs and passes DMARC, the provider's extra signature is their need.
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 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

The practical answer

Double DKIM signing is two DKIM signatures on one email. It is necessary when separate parties need distinct DKIM identities on the same message, such as your domain for DMARC and an ESP domain for a documented provider process. It is not required just because DKIM exists, and it is not the same as oversigning.
Inspect the raw headers, identify every d= and s= value, verify each DNS key, and compare every passing signature with the visible From domain. That evidence shows whether double signing exists and whether either signature contributes to DMARC.

Frequently asked questions

DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard
What you'll get with Suped
Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing