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 when two parties need their own DKIM identity on the same message, or when a provider needs its own signature for a feedback loop, routing, abuse handling, or internal reputation while still signing 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 own authentication outcome.
Counter DKIM signing is not a standard DKIM term. When someone says it, I ask them to show the raw message headers and the exact DNS records they want published. In practice, they often mean adding a second DKIM signature, changing the signing domain, or using DKIM oversigning.
What double DKIM signing means
DKIM works by adding a cryptographic signature to selected headers and the body hash of an email. The receiver looks up the public key in DNS, verifies the signature, and reports whether that specific DKIM signature passed. Multiple signatures are allowed. 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 is the one I care about for DMARC because it matches the visible From domain. The ESP-domain signature can help the ESP handle complaints, prove its own handling path, or connect the message to 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.
When double signing is necessary
Double signing is necessary when one valid signature does not satisfy every party's requirement. The most common case is a marketing platform or ESP that signs with your domain for DMARC, then also signs with its own domain so it can operate complaint feedback loops and manage provider-level reputation. That second signature is mostly for the provider, not for your DMARC pass result.
It is also useful during migrations. If you are moving mail between platforms, the old platform, new platform, or a gateway can have different signing roles for a short period. I still expect a warmup period because mailbox providers associate a DKIM domain with the sending infrastructure that is using it.
|
|
|
|---|---|---|
ESP plus brand | Often | Brand DMARC and ESP operations |
Key rotation | Sometimes | Old and new selectors overlap |
Gateway signing | Sometimes | A later system signs final mail |
Normal DMARC | No | One matching DKIM pass is enough |
Common double signing scenarios
- Required: A provider needs its own DKIM domain for feedback loops while your domain still needs to pass DMARC.
- Useful: A migration or key rotation has overlapping selectors and both paths send real mail.
- Unneeded: Your visible From domain already has a valid DKIM pass and DMARC reports show clean authentication.
- Misleading: Two DNS records alone do not prove double signing; the message header proves it.
When it is not necessary
If your ESP signs with your domain and that domain matches 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.
I do not treat lack of double signing as a problem by itself. The problem is lack of a valid signature using the right domain, broken DNS, a missing selector, body changes after signing, or a platform signing only with its own domain when you need your domain to carry the authentication result.
What matters for you
- Domain: The DKIM d= value should match your visible From domain or its parent.
- Selector: The s= value must have a valid public key in DNS.
- Result: At least one matching DKIM pass can satisfy DMARC.
What matters for the ESP
- Provider domain: The ESP can sign with its own d= domain for operational tracking.
- Feedback loops: Some complaint programs rely on the signing domain they control.
- Abuse handling: A provider signature can connect mail back to its platform.
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.
If you want the deeper version of the second concept, I keep the practical explanation 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, I check whether they are asking for a TXT public key or a CNAME delegation. Both are normal patterns. What matters is whether the requested hostname is a new selector, whether it points to the right provider key, and whether that 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, I move the conversation to concrete headers and DNS. That removes guesswork. 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.
- Signing domain: Will you sign with my domain, your domain, or both domains?
- Selector details: Which selector will appear in the s= tag, and what DNS hostname must exist?
- Feedback loop: Does the complaint feedback loop require your provider domain to sign the message?
- Final signer: Will any footer, link wrapping, or gateway change the message after DKIM signing?
- Evidence: 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 DNS records they asked for are in use.
How Suped fits into the workflow
Suped's product is useful here because the issue is rarely only DKIM syntax. The real workflow is to connect DKIM results to DMARC outcomes, sending sources, provider changes, and DNS ownership. Suped brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, and deliverability signals into one place.
For most teams, Suped is the best overall fit because it turns authentication failures into concrete fix steps instead of leaving you to compare raw XML reports and message headers manually. Its DMARC monitoring workflow helps show which sources pass, which fail, and which domains or selectors need attention.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
That matters when an ESP says a second signature, a new selector, or another DNS record is required. Suped helps you see whether the current signature is failing, whether the d= domain is the wrong domain, whether SPF is carrying DMARC instead, and whether a provider-specific request is operational rather than required for your authentication.
Practical decision path
I use a simple decision path. First, confirm whether the message has one DKIM-Signature header or more than one. Second, identify the d= domain on each signature. Third, check whether at least one passing DKIM signature matches the visible From domain for DMARC. Fourth, ask what business 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 migration, gateway, or rotation has overlapping signing paths.
Required
High
Two parties need distinct DKIM identities on the same message.
If the extra signature is for the ESP's own systems, that is 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 refuses to sign with its own domain, you can still pass DMARC, but the ESP has fewer options for provider-owned feedback loop setup.
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.
Moving ESPs without a short warmup leaves the same domain key on new infrastructure.
Expert tips
Save raw headers from a real message before debating what an ESP actually signed for you.
Use separate selectors for rotations, migrations, and provider-controlled signatures cleanly.
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 signing with the sender's domain lets reputation travel when changing ESPs, but 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 two domains need to sign the same message for different reasons, such as your domain for DMARC and an ESP domain for feedback loops or provider operations. It is not necessary just because DKIM exists, and it is not the same as oversigning.
The test is straightforward: inspect the raw headers, identify every d= and s= value, verify the DNS key, and compare the passing signature to the visible From domain. Once that is clear, the conversation with an ESP becomes specific instead of circular.
