Decoding the Chain of Trust: How to Read Multiple DKIM Signatures

You’re staring at an `Authentication-Results` header. You see two `dkim=pass` results, one from the sender's ESP and one from a forwarder. Yet the message was flagged, or worse, failed DMARC outright. How?

This isn't a hypothetical. It's a daily reality in incident response and email administration. An email is rarely a simple point-to-point delivery. It's a package passed between multiple couriers, each potentially adding their own stamp, seal, or note.

Understanding this chain of custody is non-negotiable. When an email has multiple DKIM signatures, it’s not an error. It’s a narrative of the message’s journey through various Mail Transfer Agents (MTAs). Your job is to read that narrative correctly to separate a legitimate, complex delivery from a malicious actor hiding in the noise.

Why Would an Email Have More Than One Signature?

A single email can be signed multiple times as it traverses the internet. Each signature represents a server, or a logical group of servers, taking cryptographic responsibility for the message at a specific point in time. This happens for perfectly valid reasons.

Indirect Mailflows: The Mailing List Problem

Think about a vendor sending an update to a mailing list you subscribe to, like a Google Group. The original sender, `vendor.com`, uses a platform like Mailchimp to send the message. Mailchimp applies a DKIM signature with its domain (`d=mcsv.net`). The message passes initial authentication.

But when the mailing list server receives it, it often makes changes. It might add a subject prefix like `[LISTNAME]` or append a footer with unsubscribe instructions. These modifications will break Mailchimp's original DKIM signature because the body hash, defined in RFC 6376, no longer matches. To preserve deliverability and assert its own role, the mailing list server often signs the *new*, modified message with its own DKIM key (`d=googlegroups.com`). The email now arrives in your inbox with two signatures—one broken, one passing.

Security Services: The SEG Interruption

Secure Email Gateways (SEGs) like Proofpoint or Mimecast are another common source of additional signatures. When your organization’s SEG processes an inbound email, it might rewrite URLs for time-of-click protection or add a warning banner (`[EXTERNAL]`) to the message body. Just like with mailing lists, these are modifications that invalidate the original sender's DKIM signature.

To compensate, the SEG will re-sign the email with its own DKIM key (e.g., `d=pphosted.com`). This new signature is a declaration: "I, the SEG, have altered this message for security purposes, and I attest to its current state." It provides a new, valid authentication layer, but as we'll see, it creates complications for DMARC alignment.

Reading the Authentication-Results Header

The `Authentication-Results` header is the Rosetta Stone for email authentication. It's added by a receiving MTA to record the results of its SPF, DKIM, and DMARC checks. When multiple DKIM signatures are present, you'll see multiple `dkim=` entries.

Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.info header.s=s1 header.d=sendgrid.info ...;
dkim=pass header.i=@acme-corp.com header.s=arc-2022 header.d=acme-corp.com ... — Example Authentication-Results header

Let’s break this down. The first part, `mx.google.com`, tells you who performed the check and generated this header. Each `dkim=` entry represents the result of validating one signature. The most critical piece of information here for any analyst is the `header.d=` tag. This is the domain of the signer, which is pulled directly from the DKIM signature's `d=` tag in the `DKIM-Signature` header itself.

A verdict of `pass` means the cryptographic signature was valid. The public key retrieved from the DNS record at `[selector]._domainkey.[header.d]` successfully decrypted the signature's hash, and it matched the computed hash of the email's headers and body. A `fail` means the signature didn't validate. You might also see `temperror` (e.g., DNS lookup failed) or `permerror` (e.g., key is malformed). For DMARC, only a clean `pass` matters.

The Forwarding Problem and the ARC Solution

The classic forwarding scenario is where email authentication's neat theories collide with messy reality. A forwarded calendar invite from a partner, a customer's auto-reply rule, a simple redirect—all of these are intermediate hops that break authentication. SPF (RFC 7208) breaks because the IP address changes. DKIM breaks if the forwarder modifies the message. DMARC (RFC 7489) subsequently fails, and legitimate email gets junked.

Does Signature Order Matter?

Multiple `DKIM-Signature` headers are stacked in an email, typically with the most recent one at the top. While the order specified in RFC 6376 isn't prescriptive about processing, it provides a chronological clue. The last signature added is likely from the last MTA to handle the message before it reached the final recipient's server. The first signature is usually from the original sender. By reading the `d=` domains from bottom to top, you can trace the email's path.

ARC as the Chain of Custody

This is precisely the problem Authenticated Received Chain (ARC), defined in RFC 8617, was designed to solve. ARC is a wrapper that preserves the original authentication results across multiple hops.

An ARC-aware forwarder will first validate the inbound email's SPF and DKIM. It then records these results in a new `ARC-Authentication-Results` header. It then generates its own set of ARC headers (`ARC-Seal`, `ARC-Message-Signature`) that cryptographically sign the original message headers, including the newly added ARC auth results. The final receiving MTA can then validate the ARC chain, see the original 'pass' from the legitimate sender, and trust it, even if the direct DKIM signature is now broken. ARC doesn't replace the need for multiple signatures, but it provides a standardized way to trust them in sequence.

Diagnosing the DMARC Disconnect

This is the operational payoff. You're trying to figure out why an email with passing signatures failed DMARC. The answer almost always comes down to one word: alignment.

DMARC requires two things. First, that either SPF or DKIM produces a `pass` verdict. Second, the domain used for that passing mechanism must *align* with the domain found in the `From:` header—the one the user sees. For DKIM, this means the `d=` domain in the valid signature must match (or be a subdomain of) the `From:` header's domain.

Putting It All Together: The Alignment Check

Imagine an email with the following properties:

From: billing@coolstartup.com
Authentication-Results: ...; dkim=pass header.d=sendgrid.net; dkim=pass header.d=zendesk.com

Here, we have two passing DKIM signatures. An analyst might see `dkim=pass` and move on. But that's a mistake. Let's check alignment:

The first passing signature is from `sendgrid.net`. Does `sendgrid.net` align with `coolstartup.com`? No. The second passing signature is from `zendesk.com`. Does `zendesk.com` align with `coolstartup.com`? No. Since neither of the *passing* DKIM authenticators aligns with the `From:` header domain, DKIM fails the DMARC test. If SPF also fails or is not aligned, the message's DMARC disposition will be `fail`.

This is why simply counting `dkim=pass` entries is useless. You must check which `d=` domain passed and compare it to the `From:` header. This is the fundamental difference between authentication (Did a valid signature exist?) and identifier alignment (Did the signature vouch for the identity the user sees?). It's the gap where Business Email Compromise (BEC) thrives.

The takeaway

Stop seeing multiple DKIM signatures as noise. They are a signal. Each signature is a breadcrumb left by an MTA that handled the message. Your task is to reconstruct that trail, identify which breadcrumb belongs to the original sender, and check if it aligns with the `From:` address. The other signatures from mailing lists, forwarders, and SEGs explain the *journey*, but only the aligned signature can prove the *origin* for DMARC purposes.

This manual header-by-header analysis is tedious and error-prone during a real incident. Platforms like MailSleuth.AI are built to automate this decomposition, instantly showing you which signatures passed, which failed, and crucially, which one was used for the DMARC alignment check, so you can separate a legitimate forwarded email from a cleverly disguised threat.