Multiple DKIM signatures explained: why they appear and how DMARC evaluates them

Seeing more than one DKIM-Signature: header in the same message looks suspicious the first time.

Usually it is not.

Multiple DKIM signatures are a normal part of email. The DKIM spec explicitly allows them, and DMARC does not get confused just because there is more than one signature on a message.

The important question is not "why are there several?" The important question is "did at least one relevant signature verify, and was it aligned with the visible From domain?"

Why a message can have multiple DKIM signatures

DKIM is not designed around the idea that there must be one single signature from one single actor.

The DKIM specification allows a message to contain multiple signatures from the same organization or from different organizations involved in handling the message. That makes sense operationally because email often passes through more than one system that may have a legitimate reason to sign it.

Common examples:

• the sender signs, and a mailing list or mediator adds its own signature later
• a provider signs with one domain while the customer signs with another
• a sender adds two signatures during an algorithm or infrastructure transition
• one signature is tuned for stricter coverage while another is meant to survive more in-transit modification

So the existence of multiple signatures does not mean forgery by itself.

The most common legitimate patterns

Original sender plus intermediary

This is the classic case.

An organization signs a message before handing it off. Later, a mailing list, alumni forwarder, or other mediator modifies or redistributes the mail and adds its own DKIM signature.

That can leave headers that look roughly like this:

DKIM-Signature: v=1; d=example.com; s=mx1; ...
DKIM-Signature: v=1; d=list.example.net; s=outbound; ...

Both signatures can be legitimate. They are asserting responsibility from different points in the delivery path.

Dual-signing during a transition

The DKIM RFC also describes transition scenarios where a sender adds more than one signature on purpose.

Examples include:

• supporting older and newer verifier behavior during migration
• testing a new signing setup before removing the old one
• changing what headers are covered or how tolerant the signature is to later message handling

This is similar in spirit to safe key rotation practices. During a transition window, keeping overlapping validation paths is often cleaner than a hard cutover. If selector transitions are part of the picture, DKIM selectors and key rotation playbook is the companion read.

Customer and ESP signatures together

Some mail flows end up with one DKIM signature representing the customer domain and another representing the platform actually sending the mail.

That can happen when a provider offers delegated signing, or when different parts of the pipeline sign at different stages.

From a DMARC perspective, that distinction matters a lot, because only an aligned signature helps the visible From domain pass DMARC.

How receivers evaluate multiple DKIM signatures

This is the part many admins overcomplicate.

Receivers do not need to pick a single "winner" and ignore the rest. Per RFC 6376, signatures are evaluated independently. One broken signature does not cancel out a good one.

That means this kind of result is perfectly possible:

• one signature passes
• one signature fails
• one signature is ignored because it is malformed or unusable

And the message can still be perfectly fine from a DKIM and DMARC point of view.

The receiver is allowed to stop once it finds a signature that verifies to its satisfaction, though implementations may also evaluate more than one. The practical takeaway is simple: a failed extra signature is noise unless it was the signature you actually needed.

What Authentication-Results often looks like

Delivered headers may show several DKIM outcomes, for example:

Authentication-Results: mx.example.org;
  dkim=pass header.d=example.com header.s=mx1;
  dkim=fail header.d=mailer.example.net header.s=old;
  spf=pass smtp.mailfrom=bounces.example.net;
  dmarc=pass header.from=example.com

Admins often lock onto the dkim=fail line and miss the more important part: dmarc=pass.

If one DKIM signature verified with d=example.com and aligned with From: user@example.com, DMARC can pass even while another signature on the same message failed.

If reading these headers still feels messy, DMARC troubleshooting: read Authentication-Results headers and fix alignment failures is the best refresher.

How DMARC treats multiple DKIM signatures

DMARC is very specific here.

It does not ask whether all DKIM signatures passed.

It does not ask whether most of them passed.

It asks whether at least one DKIM signature:

1. verified successfully, and
2. was aligned with the RFC5322.From domain

The DMARC RFC says a message satisfies DMARC if at least one supported authentication method produces a pass result on an aligned identifier. For DKIM specifically, a single aligned verified signature is enough.

That leads to two very common real-world outcomes.

Case 1: multiple valid signatures, only one aligned

Example:

• From: billing@example.com
• DKIM pass with d=esp-mail.example.net
• DKIM pass with d=example.com

DMARC can pass because the example.com signature is aligned.

Case 2: valid DKIM exists, but not aligned

Example:

• From: billing@example.com
• DKIM pass with d=mailer.example.net
• no aligned DKIM pass for example.com
• SPF also not aligned

Here, DMARC fails even though the message had a valid DKIM signature.

That point is where a lot of debugging goes wrong. A valid signature is not the same thing as a DMARC-useful signature.

The misconception that causes the most confusion

The wrong mental model is:

"If any DKIM signature passes, DMARC passes."

That is false.

The right mental model is:

"If any aligned DKIM signature passes, DKIM can satisfy DMARC."

Alignment is the filter that stops unrelated third-party signatures from being treated as proof that the visible From domain is authentic. That matters because mail can pick up perfectly valid signatures from intermediaries, including mailing lists and forwarders. DMARC, forwarding, mailing lists, SPF, DKIM, and ARC covers that broader path-mutation problem.

When multiple signatures are actually useful

Multiple signatures are not just tolerated. Sometimes they are operationally smart.

Useful cases include:

• staged infrastructure migration
• delegated or third-party sending arrangements
• preserving a customer-domain signature while also adding a platform signature
• handling mail that may be modified by intermediaries

There is one caution worth keeping in mind: extra signatures do not magically make a message more trustworthy. They just provide multiple validation opportunities. Receivers still apply local policy, and DMARC still cares about alignment, not signature count.

A few debugging rules that save time

When a message has several DKIM signatures, use this order:

1. Identify the visible From: domain.
2. List every DKIM result shown in Authentication-Results.
3. Mark which header.d= values are aligned with the From domain.
4. Ignore unaligned passes for DMARC purposes.
5. Investigate aligned failures first.

That workflow is much faster than trying to explain every single signature before checking whether any aligned one already passed.

Also remember that a message can contain stale or broken signatures left behind by earlier hops. RFC 6376 explicitly says one bad signature should not invalidate another good one.

Bottom line

Multiple DKIM signatures are normal.

Receivers evaluate them independently. DMARC does not require all of them to pass. It only needs one aligned DKIM pass, or one aligned SPF pass, to succeed.

So when you see two or three DKIM-Signature: headers, do not ask "which one is the real one?" Ask which one verified, which one aligned, and whether that was enough for DMARC.