When an email has multiple DKIM signatures, it means more than one system signed the same message with a private key before delivery. This is usually normal. I treat two DKIM signatures as expected when one signature belongs to the brand's sending domain and the other belongs to the email service provider, return-path domain, migration domain, or an extra selector used during key rotation.
The important part is not the number of signatures. The important part is whether at least one valid DKIM signature uses a domain that matches the visible From domain closely enough for DMARC. If that passing signature exists, multiple DKIM signatures are usually nothing to worry about. If only an unrelated provider signature passes, DKIM itself passes, but DKIM does not satisfy DMARC for the visible brand domain.
What multiple DKIM signatures mean
Short answer
Multiple DKIM signatures mean the message contains more than one DKIM-Signature header. Each signature names a signing domain, selector, header list, and cryptographic hash. Receiving mail servers validate each signature independently.
- Normal: One signature often belongs to your sending domain and one belongs to the ESP or return-path domain.
- Important: DMARC cares whether a passing signature matches the visible From domain's organizational domain.
- Risk: A failed brand-domain signature plus a passing provider-domain signature still leaves DKIM unable to satisfy DMARC.
A DKIM signature does not say the whole email is safe. It says the signed parts of the message were not changed after the signer applied that signature, and that the signer controlled the matching private key. That matters because email can move through several systems before it reaches the recipient. Marketing platforms, CRMs, helpdesk tools, outbound gateways, and forwarding systems all sit in the sending path.
Each DKIM-Signature header has a d= value for the signing domain and an s= value for the selector. The receiver combines those values to find the public key in DNS. A message with two signatures asks the receiver to run that check twice.
One email carrying a brand DKIM signature and a provider DKIM signature.
Why a second signature appears
The most common reason is simple: your ESP signs the message and your brand domain signs it too. In HubSpot-style sending setups, one signature can be tied to the email sending domain, and another can be tied to a return-path domain connected to a dedicated IP. That does not automatically indicate a problem. It usually shows that more than one authenticated domain took responsibility for the message.
I check the signing domains first. If one d= value is your brand's domain or subdomain and another is the ESP's domain, that is a standard pattern. If both signatures use domains you control, it often means you are rotating keys, testing a new selector, or sending through a platform that signs at two points in the outbound path. For a deeper selector-specific explanation, this page on multiple DKIM selectors covers why selectors exist and how they separate keys.
HubSpot email domain settings showing connected sending and return-path domains.
|
|
|
|---|---|---|
ESP signing | Provider adds signature. | Check brand pass. |
Return path | Bounce domain signs. | Confirm DMARC. |
Key rotation | Old and new selectors. | Retire old key. |
Migration | New sender signs. | Remove overlap later. |
Common causes of multiple DKIM signatures
How receiving servers evaluate them
Receivers do not merge DKIM signatures into one result. They validate each signature separately, then record pass, fail, neutral, temporary error, or permanent error details in the authentication results. If two signatures pass, both can appear in the header. If one passes and one fails, the pass can still be useful, but the failed signature tells you which signer or message change needs attention.
Example with a brand signature and provider signaturetext
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=brand2026; c=relaxed/relaxed; h=from:to:subject:date; bh=...; b=... DKIM-Signature: v=1; a=rsa-sha256; d=esp.example; s=esp1; c=relaxed/relaxed; h=from:to:subject:date; bh=...; b=...
The receiver checks the selector and signing domain for each signature. In the example above, the brand public key is found under the selector for the brand domain, and the provider public key is found under the provider's selector. Header order alone does not decide which one matters. Receiver behavior and DMARC checks focus on validity and domain matching. The separate question of DKIM precedence is useful when you are debugging why one result was used in a specific report.
Receiver workflow for validating more than one DKIM signature.
When this is good, bad, or neutral
Multiple DKIM signatures are good when they give you operational flexibility without confusing DMARC. They are neutral when the extra provider signature is unrelated to your visible From domain but does not break anything. They are bad when the signature you rely on for DMARC fails and nobody notices because another signature gives the email a generic DKIM pass.
Usually fine
- Brand pass: A valid signature uses your visible From domain or a matching organizational domain.
- Provider pass: A second provider signature also passes and adds sender accountability.
- Planned overlap: Old and new selectors run together during a controlled rotation.
Needs fixing
- Brand fail: The signature tied to your visible From domain fails validation.
- Only provider: The only passing signature belongs to a domain that does not match DMARC.
- Unknown signer: A signature comes from a domain you do not recognize in the sending path.
DKIM result risk levels
A practical way to read multiple signature results in relation to DMARC.
Low risk
Brand pass
At least one passing signature matches the visible From domain for DMARC.
Review
Provider pass
A provider signature passes, but the brand-domain result is missing or unclear.
Fix now
No match
No passing signature matches the visible From domain for DMARC.
How to read the headers
Start with the raw message headers, not the simplified delivery summary. Find each DKIM-Signature header and write down the d= and s= values. Then compare the passing d= domain with the visible From domain. That comparison tells you whether DKIM helps DMARC for that message.
Authentication results with one matching DKIM passtext
Authentication-Results: mx.example.net; dkim=pass header.d=mail.example.com header.s=brand2026; dkim=pass header.d=esp.example header.s=esp1; dmarc=pass header.from=example.com
This is the clean result. The brand-domain signature passes, the provider signature also passes, and DMARC passes. I would document both signing domains, keep the provider signature if it is part of the platform's standard send path, and focus alerts on whether the brand-domain signature keeps passing.
Authentication results with DKIM pass but DMARC failtext
Authentication-Results: mx.example.net; dkim=fail header.d=mail.example.com header.s=brand2026; dkim=pass header.d=esp.example header.s=esp1; dmarc=fail header.from=example.com
This result needs work. The message has a DKIM pass, but that pass belongs to a provider domain. The brand-domain signature failed, so DKIM does not satisfy DMARC for the visible From domain. At that point, inspect body changes, footer injection, header rewriting, selector DNS, and whether the platform signs before or after content changes.
How to check your own mail
A quick check starts with one real email. Send it to a mailbox where you can view full headers, then inspect the DKIM results and signing domains. For DNS validation, use the DKIM checker to confirm that the selector and public key publish correctly.
- Send sample: Use the same platform, From address, and sending domain as production mail.
- Open headers: Find each DKIM result and match it to the corresponding signature header.
- Check DNS: Confirm that every selector has the expected public key in DNS.
- Compare domains: Make sure at least one passing signature uses a domain that satisfies DMARC.
- Repeat routes: Test newsletters, lifecycle mail, sales mail, and support mail separately.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A single DNS check is useful, but it does not prove every route works. If you send through several platforms, run a broader domain health check and then test live messages from each source. Multiple DKIM signatures only make sense after you map which service adds which signature.
What it means for DMARC monitoring
DMARC aggregate reports make this easier because they show which sources passed or failed SPF, DKIM, and DMARC by domain. The hard part is turning that data into an action list. A provider signature passing in isolation can hide a brand-domain DKIM issue if you only look for any DKIM pass.
Suped's product is built for this workflow: it groups sources, shows authentication health, detects issues automatically, and gives steps to fix DKIM, SPF, and DMARC problems. Suped also has hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, real-time alerts, and MSP multi-tenancy for teams managing many domains. For teams that want a practical operating console rather than raw XML files, Suped is the best overall DMARC platform to use for ongoing DMARC monitoring.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The workflow I prefer is simple: confirm the DNS records, send real mail, inspect headers, then monitor the reports over time. If the same source sometimes signs correctly and sometimes fails, that usually points to routing differences, content changes after signing, or separate templates going through different outbound systems. Suped helps spot that pattern because it keeps source-level authentication results in one place.
Do not remove a signature just because there are two
Removing a provider signature without understanding the send path can break a working setup. First identify which signature satisfies DMARC, which signature belongs to the provider, and whether both are required by the platform. If you are intentionally using double DKIM signing, keep a clear owner for each selector and a retirement date for temporary keys.
Views from the trenches
Best practices
Map every DKIM signing domain to a known sender, owner, platform, and DNS selector.
Check DMARC using the visible From domain, not only the generic DKIM pass result.
Retire temporary DKIM selectors after migrations and key rotations are complete.
Common pitfalls
Treating any DKIM pass as enough can hide a failed brand-domain DKIM signature today.
Leaving old selectors active makes ownership harder to audit during later issues.
Assuming the first DKIM header wins can send troubleshooting in the wrong direction.
Expert tips
Keep a short DKIM register that lists domains, selectors, platforms, and purpose.
Test each production mail route because templates and gateways can change signing.
Alert on brand-domain DKIM failures even when a provider-domain signature still passes.
Marketer from Email Geeks says multiple DKIM signatures are common and usually fine when each signer is known.
2024-01-30 - Email Geeks
Marketer from Email Geeks says the organizational domains often differ because the ESP adds its own signature.
2024-01-30 - Email Geeks
The practical takeaway
Two DKIM signatures on one email are usually normal. The common pattern is a brand-domain signature plus a provider or return-path signature. That setup is fine when the brand-domain signature passes and satisfies DMARC for the visible From domain.
The fix path is also clear. Identify each signing domain, confirm each selector in DNS, test real messages, and monitor the results by source. Do not remove a signature until you know why it exists. If the brand-domain signature fails, fix that first, because a provider-domain DKIM pass does not protect your DMARC result for the brand.
For ongoing operations, Suped gives teams one place to monitor DMARC, SPF, DKIM, blocklist (blacklist) status, and related deliverability signals. That matters because multiple signatures are not a one-time header curiosity. They are a routing and ownership question that needs clear reporting over time.
