The DKIM Signature That Counts: How Receivers Evaluate Multi-Signed Email

An alert fires. A high-priority email, supposedly from your CFO, was just quarantined. You pull the headers expecting a clear-cut spoof, but what you find is more confusing: three different DKIM-Signature headers, and a quick check shows all three are cryptographically valid. Yet, the final DMARC verdict from Microsoft 365 is a hard `fail`. This isn't a bug; it's a feature of modern email delivery.

Emails rarely travel a straight line from sender to receiver anymore. They pass through marketing automation platforms, secure email gateways (SEGs), and sometimes complex forwarding rules. Each hop can add its own layer of identity, its own digital signature, creating a stack of credentials that the final mail server must untangle.

The core question for any SOC analyst or mail admin is simple: When an email presents multiple forms of ID, which one does the bouncer trust? The answer lies in a precise, and sometimes unforgiving, evaluation process dictated by DMARC alignment.

The Journey of an Email: A Cascade of Signatures

Before you can diagnose a DMARC failure on a multi-signed message, you have to understand why those signatures exist in the first place. Think of an email's journey not as a single flight, but as a series of connecting flights. Each leg of the trip is handled by a different carrier, and some of them have their own security procedures.

The process often starts with a third-party service. Your marketing team uses a platform like HubSpot or Mailchimp to send a newsletter. That platform will sign the email with its own DKIM key, creating the first signature. This signature proves the email originated from their infrastructure. The signing domain (`d=`) in this header will be something like `hubspot.com`.

Next, the email hits your own company's outbound email gateway, perhaps a service like Mimecast or Proofpoint. Your organization has configured this SEG to also sign outgoing mail, this time using a DKIM key associated with your actual corporate domain. The SEG adds a *second* DKIM-Signature header. This signature attests that the message passed through your sanctioned outbound gateway. The signing domain here will be your own, like `d=your-company.com`.

So, even before the email leaves your perimeter, it already has two valid signatures. This is a legitimate, common mail flow. The existence of multiple signatures is a map of the email's provenance, not an immediate sign of tampering.

Header Forensics: Tracing the Chain of Custody

When the receiving mail server, such as Microsoft 365 Exchange Online Protection (EOP), gets this email, it doesn't just pick one signature at random. It evaluates all of them and summarizes its findings in the `Authentication-Results` header, a crucial piece of forensic evidence defined in RFC 8601.

Deconstructing the Authentication-Results Header

This header is your ground truth. It’s the receiver telling you exactly what it tested and what it concluded. Forget what you think your sending configuration is; this header shows what the recipient actually saw. It's the MTA's lab report.

Authentication-Results: spf=pass (sender IP is 1.2.3.4) smtp.mailfrom=bounces.sendgrid.net; dkim=pass (signature was verified) header.d=sendgrid.net; dkim=pass (signature was verified) header.d=example.com; dmarc=fail action=quarantine header.from=example.com; — Example Authentication-Results header

Mapping Signatures to Senders

Let's break down the example above. We see two `dkim=pass` results. The first one is for `header.d=sendgrid.net`. This is the signature from the originating platform. The cryptographic verification passed, so the signature is valid. The second is for `header.d=example.com`. This is the signature likely added by an outbound gateway configured to sign for the author's domain. It also passed verification.

So we have two valid signatures. We also have an SPF pass, but notice it's for `smtp.mailfrom=bounces.sendgrid.net`. Then we see the final, damning verdict: `dmarc=fail`. The key to this entire puzzle is the `header.from=example.com` field. This is the domain the user sees in their mail client, and it's the domain that DMARC is trying to protect.

The Alignment Check: Where Most Multi-Signed Emails Fail

This brings us to the most misunderstood aspect of DMARC: identifier alignment. DMARC (RFC 7489) doesn't just care that SPF or DKIM passed. It demands that the domain that passed authentication *aligns* with the domain in the `From:` header.

Identifier Alignment: The Deciding Factor

Let's apply this to our `Authentication-Results` header. The `From:` header domain is `example.com`.

First, the receiver checks the SPF result. The authenticating domain was `bounces.sendgrid.net`. Does this align with `example.com`? Not even close. So, for DMARC purposes, the SPF pass is ignored. This is a common setup for third-party senders that handle their own bounces.

Next, the receiver moves to DKIM. It inspects the signatures. Receivers typically process headers from the bottom up, evaluating the most recently added signatures first. It finds a `dkim=pass` for `header.d=sendgrid.net`. Does `sendgrid.net` align with `example.com`? No. This signature is cryptographically sound, but it doesn't help with DMARC for the `example.com` domain. It's the wrong ID for the person you're trying to be.

Then it finds the second `dkim=pass` for `header.d=example.com`. Does `example.com` align with `example.com`? Yes. This is called a DKIM alignment success. Because the receiver found at least one authentication mechanism (in this case, DKIM) that both passed and aligned, the DMARC check *should* pass.

So Why Did It Fail?

In our example header, we have a clear DMARC fail despite finding an aligned pass. Why? The most common reason is that the aligned signature itself was invalid. Perhaps a downstream mail gateway added a footer or a disclaimer *after* the `d=example.com` signature was applied, breaking the body hash and invalidating the signature. The `Authentication-Results` header can sometimes be misleadingly simple. It might show `dkim=pass` for one signature and omit the `dkim=fail` for the one that actually mattered for alignment. The receiver found no signatures that were *both* valid and aligned, leading to a DMARC failure.

Preserving the Chain of Trust with ARC

The entire system becomes even more fragile with email forwarding. A user forwarding an email from their work account to a personal one, or any traffic passing through a mailing list, is a notorious source of DMARC failures. The forwarder is an intermediary MTA that often breaks original DKIM signatures by modifying the body (e.g., adding a subject prefix like `[EXT]`) and breaks SPF because its IP address isn't in the original sender's SPF record.

This is the exact problem that the Authenticated Received Chain (ARC), defined in RFC 8617, was designed to solve. ARC acts as a wrapper for authentication results, preserving them across hops.

How ARC Works in Practice

When an ARC-aware forwarder receives an email, it first validates the existing authentication (SPF, DKIM, DMARC). It then records these results in a new set of headers: `ARC-Authentication-Results`. It then cryptographically signs this summary with its own `ARC-Seal` and `ARC-Message-Signature`. This package is passed along with the forwarded email.

The final receiver, like Gmail or M365, sees that the direct SPF and DKIM checks fail. But it also sees the ARC headers. It can validate the ARC seal, see which forwarder added it, and check the enclosed original authentication results. If the receiver trusts the forwarder (e.g., Google trusts that a Microsoft 365 server is a legitimate forwarder), it can choose to honor the original `dmarc=pass` verdict that ARC preserved.

ARC essentially allows an intermediary to vouch for the email's authenticity at the time it was received. It's not a silver bullet—not all systems support it, and trust decisions are up to each receiver—but it's the industry's best attempt at fixing the damage caused by legitimate mail flow intermediaries.

The takeaway

Multiple DKIM signatures aren't an error code; they're a roadmap of an email's journey through the internet. The key for any security analyst is to move beyond a simple `pass` or `fail` verdict and ask the right questions: Which signature passed? Was it the one that aligned with the `From:` header? And if not, what broke the one that mattered?

Reading raw headers to trace this logic is tedious and prone to error. This is where automated header analysis becomes critical for a modern SOC. A tool like MailSleuth.AI can parse the entire chain, instantly showing which signature was evaluated for DMARC, why others were ignored, and whether an ARC chain preserved an earlier result. The next time you see a DMARC failure on a multi-signed email, don't just blame the sender. Follow the signatures. The story is written in the headers.