Multiple DKIM Signatures: Which One Actually Counts?

Two Signatures, One Message

Open the raw headers of a message from any large sender and you'll often find more than one DKIM-Signature header. Not a duplicate, not a mistake — two genuinely different signatures, each with its own selector, its own domain, and its own set of covered headers.

This is normal, deliberate, and considerably more useful than it looks. It's also the source of a specific class of authentication confusion: which signature actually satisfied DMARC? Because the answer is frequently "not the one you were looking at."

Why Multiple Signatures Exist

Algorithm transition

The most common reason today. A domain signing with both RSA-2048 and Ed25519 can move toward a modern algorithm without breaking verification for receivers that don't support the new one.

Verifiers evaluate the signatures they understand and ignore the rest. A receiver supporting only RSA validates the RSA signature and passes. A receiver supporting Ed25519 validates that one. Nobody fails because of an unsupported algorithm.

The same pattern applies to key length migration — sign with both the old 1024-bit key and the new 2048-bit key during the transition window, then drop the old one once reporting confirms nothing depends on it.

Third-party sending platforms

Send through an email service provider and you'll typically see two signatures: one from your domain using a selector you (or they) published in your DNS, and one from the provider's own domain.

DKIM-Signature: v=1; a=rsa-sha256; d=yourbrand.com; s=esp1; ...
DKIM-Signature: v=1; a=rsa-sha256; d=espvendor.net; s=default; ...

The provider signs with their domain because it protects their reputation and helps their deliverability across their whole platform. Your signature is the one that matters for your DMARC.

Subdomain and parent domain signing

Some architectures sign with both mail.example.com and example.com, which affects alignment depending on your DMARC adkim setting.

Signing at multiple hops

A message may be signed by the originating system and again by a gateway, a security appliance, or a relay on the way out.

The Alignment Question

Here's where multiple signatures cause real confusion.

DMARC doesn't care whether a DKIM signature validated. It cares whether a signature validated with a d= domain that aligns with the From header domain.

Consider a message:

From: [email protected]

DKIM-Signature: d=espvendor.net; s=default;   → validates ✓
DKIM-Signature: d=yourbrand.com; s=esp1;      → fails ✗

A naive check reports "DKIM passed." It did — one signature validated perfectly. But the validating signature is on espvendor.net, which doesn't align with yourbrand.com in the From header. DMARC fails on the DKIM side.

If SPF is also failing or unaligned, the whole message fails DMARC and gets quarantined or rejected under an enforcement policy.

This is the single most common source of "our DKIM passes but DMARC reports show failures." The signature that passes and the signature that needs to pass are different signatures.

Strict vs relaxed alignment

DMARC's adkim tag controls how alignment is judged:

• adkim=r (relaxed, the default): the signing domain may be a subdomain of the From domain, or vice versa. mail.yourbrand.com aligns with yourbrand.com.
• adkim=s (strict): the domains must match exactly. mail.yourbrand.com does not align with yourbrand.com.

Switching to strict alignment without auditing every sending path is a reliable way to break legitimate mail from a subdomain-signing platform.

Checking Your Selectors

Every signature references a selector, and that selector must resolve in DNS. The DKIM Checker queries the record directly:

1. Enter your domain.
2. Enter the selector name.
3. The tool queries selector._domainkey.yourdomain.com and reports the published record.

The awkward part is that selectors aren't discoverable. There's no way to enumerate which selectors a domain has published — DNS doesn't support listing subdomains of a zone from outside. You have to know the name.

Where to find them:

• Read the s= tag in a DKIM-Signature header of an actual message you've sent. This is the most reliable source.
• Check your ESP's documentation. Most publish the selector names they use, often something like s1 and s2, or a platform-specific prefix.
• Read your DMARC aggregate reports. They list the DKIM domains and selectors observed in the wild.
• Try common defaults if you're guessing: default, selector1, selector2, google, k1, mail, dkim.

Once you have the list, check every one. A stale selector left in DNS after a platform migration is harmless but untidy; a missing selector that's still being used to sign is an active failure.

Building an Inventory

For any domain sending from more than one system, the useful exercise is a table:

That fourth row is the problem. The CRM signs only with the vendor's domain, so DKIM can never align. Mail from that system depends entirely on SPF alignment — and if the return-path is also the vendor's domain, it fails DMARC completely.

The fix is to get the vendor to sign with your domain, which nearly all reputable platforms support. It requires publishing a CNAME or TXT record in your DNS pointing at their key.

DMARC aggregate reports are the fastest way to build this inventory, because they show you what receivers actually observed rather than what you believe your setup to be.

Verification Order and Practical Behaviour

The DKIM specification allows a verifier to evaluate signatures in any order and to stop once one validates. In practice:

• Verifiers may impose a limit on how many signatures they'll check, to prevent resource exhaustion attacks. A message with twenty signatures may not have all of them evaluated.
• Some verifiers prioritise signatures whose d= aligns with the From domain, precisely because that's the one DMARC needs.
• A failing signature is not itself a problem — DKIM is designed so that failures are neutral, not negative. A message with one failing and one passing signature is treated as passing.

That last point matters: you cannot hurt yourself by adding a signature. The worst case is that it's ignored. This makes dual-signing during migrations genuinely safe.

Practical Tips

Always check alignment, not just validity. "DKIM passed" is not the question. "Did an aligned signature pass?" is.

Keep selector names meaningful and dated. mkt-2026q1 tells you what it's for and when it was created. selector1 tells you nothing when you're auditing three years later.

Don't delete old selectors immediately after rotation. Messages already in transit or sitting in a queue may still need the old key to verify. Leave it published for a reasonable overlap period, then remove it.

Verify every selector you publish resolves correctly. A typo in a long public key breaks signing silently — messages still send, they just fail verification.

Watch the DNS record length. A 2048-bit public key exceeds the 255-character limit of a single TXT string and must be split into multiple quoted strings within one record. Some DNS providers handle this automatically; some don't, and getting it wrong produces a record that looks fine and doesn't work.

Audit after every vendor change. New platform, new selector, new alignment question.

FAQ

Can a message have more than two DKIM signatures? Yes, there's no protocol limit. Verifiers may cap how many they evaluate, so a very large number is counterproductive.

Does a failing signature hurt deliverability? Not directly — DKIM failures are neutral rather than negative. What hurts is having no aligned passing signature when DMARC requires one.

How do I find out which selectors my domain uses? Read the s= tag from a message you've sent, check your ESP's documentation, or examine your DMARC aggregate reports. DNS can't be enumerated from outside.

Should I sign with both RSA and Ed25519? Dual signing is a safe migration strategy. Ed25519 support among verifiers is not universal, so keeping an RSA signature alongside it avoids losing verification anywhere.

What's the difference between relaxed and strict DKIM alignment? Relaxed allows subdomain relationships between the signing domain and the From domain; strict requires an exact match.

The Takeaway

Multiple DKIM signatures are a feature, not a symptom — but they make "did DKIM pass?" an ambiguous question. Build an inventory of every sending system, every d= domain, and every selector, and check alignment for each. That table usually reveals the one path that's been quietly failing DMARC all along.

Verify your DKIM records free with the DKIM Checker at sadiqbd.com — no sign-up, instant results.