The short answer is that the ARC-Message-Signature header contains a cryptographically signed copy of the message's authentication state. This is a crucial part of the Authenticated Received Chain (ARC) protocol, which is designed to preserve email authentication results as a message travels through various email servers.
Email authentication methods like SPF and DKIM are fantastic, but they can run into problems when an email is forwarded or passes through a mailing list. These intermediaries can alter the message in ways that break the original signatures, causing legitimate emails to fail DMARC validation. ARC was created to solve this very problem.
By adding a new layer of authentication, ARC allows each server in the email's path to see a validated chain of custody, helping the final receiving server make a more informed decision about the email's authenticity.
The ARC header set
ARC isn't just one header; it's a set of three headers that work together. Each intermediary that handles the message adds its own set of these headers, creating a chain. The three headers are:
- ARC-Authentication-Results (AAR): This header records the initial email authentication results (SPF, DKIM, and DMARC) when the message is first received by an ARC-participating server. It’s like a snapshot of the message’s authentication status at that moment.
- ARC-Message-Signature (AMS): This is the core header that addresses your question. It contains a cryptographic signature that covers the message content and key headers, including the ARC-Authentication-Results header. This signature essentially validates the snapshot taken by the AAR header.
- ARC-Seal (AS): This header contains a signature of the previous ARC headers (AAR and AMS). It links the ARC sets together, ensuring the entire chain is tamper-proof. As the official IETF documentation puts it, this header 'includes a digital signature of all preceding ARC message header fields on the message.'
How the ARC-Message-Signature works
The ARC-Message-Signature is what preserves the message's state. When a server like a mailing list receives an email, it first validates the existing SPF and DKIM records. It records these results in the ARC-Authentication-Results header.
Next, before potentially modifying the email (like adding a footer), the server creates the ARC-Message-Signature. It uses a private key (similar to DKIM) to sign the message body and headers, locking in the authentication results it just recorded. This signature is the cryptographic proof of what the message looked like and how it authenticated at that specific hop.
When the final receiving server gets the message, the original DKIM signature might be broken. However, it can now check the ARC chain. It verifies the ARC-Seal to trust the chain, then validates the ARC-Message-Signature. If the signature is valid, the server can look at the authenticated ARC-Authentication-Results and see that the email was, in fact, legitimate when it reached the intermediary. This allows the receiving server to trust the email, even if its current state would fail DMARC.
In summary
To directly answer the question: the ARC-Message-Signature header contains the cryptographic signature of the message's state. It works alongside the ARC-Authentication-Results and ARC-Seal headers to create a trusted and verifiable chain of custody for emails, solving a common problem for forwarded messages and mailing lists.
