What does it mean when an email has multiple DKIM signatures?
Published 15 Jun 2025
Updated 5 Oct 2026
14 min read
Summarize with
Updated on 5 Oct 2026: We clarified how mixed DKIM results affect DMARC and added checks for message changes and selector DNS.
When an email has multiple DomainKeys Identified Mail (DKIM) signatures, more than one system or signing step added a cryptographic signature to the same message before delivery. This is usually normal. A common setup has one signature for the brand's sending domain and another for the email service provider (ESP) or another known system in the delivery path. A controlled migration can also use deliberate dual-signing.
The important part is not the number of signatures. Check whether at least one verified DKIM signature uses a domain that has DMARC alignment with the visible From domain. Under relaxed alignment, the domains share an organizational domain. Under strict alignment, they must be identical. If an aligned signature passes, multiple DKIM signatures are usually nothing to worry about. If only an unrelated provider signature passes, DKIM passes but does not satisfy DMARC for the visible brand domain. DMARC can still pass through SPF if its authenticated MAIL FROM domain has the required match with the From domain. This rule is defined in RFC 9989.
What multiple DKIM signatures mean
Short answer
Multiple DKIM signatures mean the message contains more than one DKIM-Signature header. Each signature has its own signing domain, selector, signed header list, and signing algorithm. Receiving mail servers evaluate each signature on its own merits.
- Normal: One signature often belongs to your sending domain and one belongs to the ESP or another known system in the delivery path.
- Important: DMARC passes through DKIM when any verified signature has strict or relaxed alignment with the visible From domain, as required by the domain's DMARC policy.
- Risk: A failed brand-domain signature plus a passing unrelated provider-domain signature leaves DKIM unable to satisfy DMARC, unless another signature passes with the required domain match.
A DKIM signature does not say the whole email is safe. It shows that the body content and header fields covered by that signature survived verification, and that the signer controlled the matching private key. It does not prove that every header was protected or that the sender is trustworthy. That distinction matters because email can move through marketing platforms, CRMs, helpdesk tools, outbound gateways, and forwarding systems before it reaches the recipient.
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 can require two separate key lookups and verification attempts.
One email carrying a brand DKIM signature and a provider DKIM signature.
Why a second signature appears
A common reason is that your ESP signs with both its own domain and your brand domain using a key delegated to it. In sending setups such as HubSpot, one signature can be tied to the connected email sending domain while another belongs to the platform's infrastructure. Dedicated IP and return-path settings can affect which infrastructure handles the message, but the Return-Path domain itself is not the DKIM identifier that DMARC compares with the visible From domain.
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 can indicate deliberate dual-signing or a migration between senders. Routine key rotation does not require both selectors to sign every message. A common rotation switches the signer to the new selector while keeping the old public key in DNS long enough for in-flight mail to verify. The explanation of 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 a signature. | Check the aligned pass. |
Gateway or forwarder | Another hop re-signs. | Map the delivery path. |
Dual-signing | Two selectors sign during a transition. | Set a retirement date. |
Migration | A new sender also signs. | Remove overlap later. |
Algorithm transition | One system signs with different signing algorithms. | Check receiver compatibility before retiring a signature. |
Common causes of multiple DKIM signatures
Multiple signatures vs multiple DKIM records
Multiple signatures on one email are not the same as multiple DKIM records for one domain. Signatures are headers attached to a message. DKIM records publish public keys in DNS. A domain can safely publish keys for several sending services because each selector has a separate DNS name.
Separate DNS names for separate selectorstext
marketing._domainkey.example.com support._domainkey.example.com workspace._domainkey.example.com
Each signature tells the receiver which key to request by combining its s= selector with its d= signing domain. Use a unique selector for each active key or sending service. Do not publish competing DKIM key records at the same selector name, because the receiver needs one usable key result for that lookup. One TXT record split into quoted character strings is still one record. A provider-supplied CNAME can point the selector to a hosted TXT key record. Publishing several selector records does not add signatures by itself. A sending system adds a signature only when it is configured to sign with the matching private key.
How receiving servers evaluate them
Receivers do not merge DKIM signatures into one cryptographic result. Each signature has independent meaning. A failed signature does not invalidate a passing one. A DKIM verifier can stop after a satisfactory pass or limit how many signatures it checks; for DMARC, a provider-only pass is not a substitute for checking signatures with the required domain match. When several are evaluated, the results can include pass, fail, neutral, temporary error, or permanent error details in Authentication-Results. A missing result for one signature does not prove that its header was absent. Independent signature evaluation is defined in RFC 6376.
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 uses the selector and signing domain in each signature it evaluates. In the example above, the key lookups are brand2026._domainkey.mail.example.com and esp1._domainkey.esp.example. DKIM defines no winning signature, and header order does not decide which signature matters. For DMARC, the useful result is any verified signature whose signing domain has the required alignment with the visible From domain. The separate discussion of DKIM precedence helps explain why receiver output can emphasize one result over another.
Receiver workflow for validating more than one DKIM signature.
Why one DKIM signature passes and another fails
Signatures can cover different versions of the message. A mailing list that adds a footer or changes a signed Subject header can break the original signature, then add a valid signature for the changed message using its own domain. Basic forwarding that leaves signed content unchanged normally preserves DKIM. M3AAWG's DKIM summary explains how these changes affect verification.
- Body hash mismatch: compare the original and delivered message bodies, including added footers and MIME encoding changes.
- Signed header changes: inspect each signature's h= list to see whether a rewritten header was covered.
- Key lookup errors: check each s= and d= combination for missing keys or temporary DNS errors.
- Content normalization: compare the c= settings. Relaxed canonicalization tolerates certain whitespace changes, but not added footers or arbitrary content changes.
DKIM canonicalization and DMARC domain alignment are separate settings. Sign after final content changes whenever you control the sender. A new provider or mailing-list signature does not repair the original signature or authenticate the original From domain for DMARC unless its own signing domain has the required match.
When multiple DKIM signatures need attention
Multiple DKIM signatures are normal when they identify known systems or support a planned transition. Investigate a failing signature that your sending setup relies on, even if another signature passes. A single failure does not automatically cause DMARC failure or spam placement; check for another passing signature with the required domain match or an SPF pass with the required domain match.
Usually fine
- Brand pass: A valid signature uses a domain with the required DMARC alignment to the visible From domain.
- Provider pass: A second provider signature also passes and identifies another responsible signer.
- Planned overlap: Two selectors sign during a controlled dual-signing transition.
Needs review
- Brand fail: The signature intended to authenticate your visible From domain fails validation, even if another result keeps DMARC passing.
- Only provider: The only passing signature belongs to a domain that does not have DMARC alignment.
- Unknown signer: A signature comes from a domain you do not recognize in the sending path.
DKIM and DMARC authentication checks
Authentication outcomes to review, rather than a prediction of inbox placement.
DKIM satisfies DMARC
Matching DKIM pass
At least one passing signature has the required DMARC alignment with the visible From domain.
Check the brand signature
Provider pass
A provider signature passes, but the aligned brand-domain result is missing or unclear.
Check SPF too
No matching DKIM pass
No passing DKIM signature has the required domain match. DMARC still passes if SPF passes with its required domain match; otherwise investigate the authentication failure.
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 each passing d= domain with the visible From domain. Relaxed DKIM alignment, the default, requires the same organizational domain. Strict alignment requires an exact domain match. Your DMARC record's adkim= setting determines which test applies. Use the Authentication-Results header added by your receiving service or an explicitly trusted gateway. An untrusted sender can insert misleading results, as described in RFC 8601.
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 with relaxed alignment, the provider signature also passes, and DMARC passes. 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 aligned brand-domain signature keeps passing.
Authentication results with DKIM pass but DMARC failtext
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=esp.example; 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. SPF passes here too, but its MAIL FROM domain is unrelated to example.com, so it cannot supply the DMARC pass. An SPF pass for a domain with the required match would change the DMARC result to pass. 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 Suped's DKIM checker to confirm that the selector and public key publish correctly. A DNS lookup alone cannot verify the signature on a delivered message.
- 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 active selector resolves to the expected TXT public key, following a CNAME if the provider uses one.
- Compare domains: Make sure at least one passing signature has the DMARC alignment your policy requires.
- 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 show source-level authentication results and the domain-match tests used for DMARC. Under RFC 9990, attempted DKIM validations must be reported, subject to reasonable limits. Reports prioritize a pass with strict alignment, then a pass with relaxed alignment, other passes, and failures, with no more than 100 signatures recommended per row. A report can therefore include a subset rather than every signature in the raw headers. Compare the raw results in auth_results with the domain-match results in policy_evaluated; a raw provider DKIM pass does not by itself establish a DMARC pass.
Suped's DMARC monitoring product groups reported authentication data by source and signing domain, so teams can distinguish a reported brand-domain DKIM failure from an unrelated provider-domain pass. It also keeps authentication history and remediation steps together, which helps when the same platform signs differently across mail routes. Use those results to investigate recurring failures with DMARC monitoring in Suped.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
A practical workflow is to 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 keeps source-level authentication results in one place to help spot that pattern. If a signature result is missing from a report, inspect raw headers; report analysis cannot recover results the receiver did not include.
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 and selector to its sending platform and responsible owner.
Check DMARC against the visible From domain using both DKIM and SPF domain-match results.
Retire temporary DKIM selectors only after old signing stops and in-flight mail clears.
Common pitfalls
Treating any DKIM pass as enough can hide a failed brand-domain signature in your reports.
Deleting old DKIM keys too soon prevents delayed mail from verifying its older signatures.
Assuming the first DKIM header wins can send troubleshooting in the wrong direction.
Expert tips
Keep a DKIM register with signing domains, selectors, platform owners, and key rotation dates.
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
Managing DKIM signatures in production
Identify each signing domain, confirm each selector in DNS, test real messages, and monitor the results by source. Keep a clear owner for each selector and retain old public keys until delayed messages no longer need them. Do not remove a signature until you know why it exists.
If the brand-domain signature fails, investigate it even when another result keeps DMARC passing. Suped's DMARC reporting product helps track those reported failures by source over time. A passing DKIM signature supports authentication; it does not guarantee inbox placement.
