What is the primary purpose of the 'h=' tag in ARC?

The h= tag in the ARC-Message-Signature header lists all the specific email header fields that were included in the cryptographic signature. This information is crucial for any receiving server to properly validate the signature and verify the integrity of those headers.

How do the three ARC headers work together?

The ARC-Authentication-Results records the previous hop's authentication status. The ARC-Message-Signature signs the message content and selected headers. The ARC-Seal then cryptographically seals the ARC-Authentication-Results and ARC-Message-Signature from the current hop, creating a chain of trust.

Why is ARC important for DMARC validation?

ARC helps preserve DMARC validation for legitimate emails that pass through intermediaries (like mailing lists) that might otherwise break SPF or DKIM, causing a DMARC failure. If the ARC chain is valid, the receiving server can consider the original authentication despite the forwarding changes.

What happens if a signed header field is altered after an ARC signature?

If any header field listed in the h= tag of the ARC-Message-Signature is altered, the cryptographic signature will no longer match. This will cause the ARC validation for that hop to fail, indicating potential tampering or an illegitimate modification.

What ARC header contains the list of signed header fields? - ARC - Email authentication - Knowledge base

An email envelope secured by digital signatures, illustrating the role of ARC headers in email authentication.

When an email passes through various intermediaries, like mailing lists or forwarders, its original authentication (SPF and DKIM) can break. This is where the Authenticated Received Chain (ARC) comes into play, designed to preserve the authentication results across these hops. ARC allows subsequent receivers to verify the legitimacy of the email, even if its authentication status changed during transit.

The key to this integrity lies in specific ARC headers that contain cryptographic signatures of the message's state. To answer the question directly, the ARC-Message-Signature header is what contains the list of signed header fields within the email, among other critical data.

The ARC-Message-Signature header and its 'h=' tag

The ARC-Message-Signature header, often abbreviated as AMS, is one of the three main ARC headers. Its primary function is to create a cryptographic signature of key parts of the email, including the message body and specific header fields. This signature ensures that these elements haven't been tampered with since the last hop that applied an ARC signature.

Within the ARC-Message-Signature header, the h= tag explicitly lists all the header fields that were included in the signature calculation. This is crucial for verification because a receiver needs to know exactly which headers were signed to properly validate the ARC-Message-Signature. If any of these signed headers are altered after the signature is applied, the verification will fail.

The choice of which headers to sign is important for maintaining trust. Commonly signed headers include From, Subject, Date, and To. You can find more details on how this header works in our article on the ARC-Message-Signature header.

The ARC-Message-Signature is analogous to the DKIM-Signature header in some ways, particularly concerning how it lists signed fields. While DKIM signs the original message, ARC extends this concept to intermediaries, allowing them to attest to the state of the email as they received and re-transmitted it. This helps build a cryptographically signed copy of the message's state at each step.

Securing the chain with ARC-Seal

While the ARC-Message-Signature signs the message itself, the ARC-Seal header plays a unique role in securing the entire chain of authentication. This header cryptographically seals the previous ARC-Authentication-Results and ARC-Message-Signature headers, creating a verifiable link in the chain. Essentially, it signs a summary of the previous ARC records and the current Authentication-Results header. Understanding the purpose of the ARC-Seal header is key to grasping ARC's overall function.

The ARC-Seal itself includes various tags, such as i= (ARC instance number) and s= (selector), but unlike ARC-Message-Signature, it does not have an h= tag to list signed header fields of the original message. Its role is to confirm the validity of the previous ARC entries and the authentication results, which in turn implicitly validates the headers signed by the AMS header in that specific ARC set. You can read more about ARC-Seal signatures in the RFC 8617.

A visual representation of chained ARC headers, demonstrating how each header cryptographically seals the previous ones for email integrity.

This mechanism ensures that a receiving mail server can look at the ARC-Seal chain and determine if the email's authentication status has been legitimately passed along or if it has been forged. If the ARC-Seal validates correctly, it suggests that the ARC-Message-Signature (and thus the signed headers) are authentic for that hop. This helps in maintaining email trust and reputation.

Monitoring your ARC records, including the ARC-Seal and ARC-Message-Signature, is critical for understanding how your email deliverability is performing, especially for complex sending scenarios. Tools like Suped provide detailed insights into ARC validation status.

Importance for email deliverability and authentication

Understanding which ARC header contains the list of signed fields is vital because it directly impacts email deliverability. Mail servers use ARC to evaluate the authenticity of an email that has been modified in transit, such as when it passes through a mailing list or forwarding service. Without ARC, these legitimate emails might fail DMARC, SPF, or DKIM checks upon arrival, leading them to be flagged as spam or rejected.

When an email is forwarded, the From header might remain the same, but the email's Return-Path often changes. This can break SPF authentication. Similarly, changes to the message body or certain headers can invalidate the DKIM signature. ARC provides a way for the intermediate server to attest to the original authentication results (using the ARC-Authentication-Results header) and then cryptographically sign those results along with the message (via ARC-Message-Signature) and the entire chain (with ARC-Seal). This allows the final recipient to see a verified history of the email's authentication status.

Best practices for ARC

Monitor reports: Regularly review DMARC reports to identify any ARC-related authentication failures and address issues.
Implement DMARC: Ensure your domain has a strong DMARC policy. ARC acts as a complement to DMARC, helping to preserve authentication for legitimate emails that would otherwise fail.
Check headers: Verify that your intermediaries (e.g., ESPs, mailing list managers) are correctly signing and sealing ARC headers.

For organizations leveraging DMARC, ARC is particularly valuable. When an email fails SPF or DKIM due to forwarding, but the ARC chain validates successfully, the receiving server can use this information to override a DMARC failure. This prevents legitimate emails from being incorrectly blocked or sent to spam folders. Suped helps you monitor your DMARC implementation and provides AI-powered recommendations to ensure your emails reach the inbox.

Components of a complete ARC set

To fully understand the context of signed header fields, it's important to recognize that ARC operates using a set of three headers that work in conjunction. These three main ARC header fields are: ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. Each one contributes to the overall integrity and verifiability of the email's authentication journey.

The ARC-Authentication-Results header (AAR) is essentially a copy of the Authentication-Results header from the previous hop. It serves as a record of the authentication decisions made by the server that handled the email prior to the current ARC signer. This header is then cryptographically included in the ARC-Seal, solidifying the historical authentication status. To learn more about this, check out our guide on what ARC header indicates the chain of authentication results.

ARC header	Primary function	Key tag for signed fields
ARC-Authentication-Results	Records previous authentication results (SPF, DKIM, DMARC).	None (records status, not signed fields).
ARC-Message-Signature	Cryptographically signs the message body and selected headers.	h= (lists signed header fields).
ARC-Seal	Cryptographically seals the entire ARC chain, including previous ARC headers.	None (seals the chain, not individual message headers).

Together, these three headers form a complete ARC set for each hop. When a new intermediary processes an email, it adds a new set of ARC headers, building a verifiable chain that traces the email's path and its authentication status through potentially modifying stages. This chain validation is essential for maintaining trust in forwarded messages.

Ensuring trusted email flow

The ARC-Message-Signature header is where you'll find the explicit list of signed header fields in the h= tag. This tag is a critical component of ARC, providing transparency and verifiability for each step of an email's journey through intermediaries. By signing specific headers and the message body, ARC helps ensure that the content remains untampered.

The full ARC protocol, comprising the three core headers, creates a robust mechanism for preserving authentication data. This allows receiving mail servers to make informed decisions about email authenticity, even when direct SPF or DKIM validation might fail. By understanding these headers, you can better diagnose deliverability issues and ensure your legitimate emails reach their intended recipients.