What problem does ARC solve for email authentication?

ARC solves the problem of legitimate email forwarding breaking traditional authentication protocols like SPF and DKIM. When an email is forwarded, its headers or body might be altered, causing DMARC checks to fail even for authentic messages.

How do the ARC headers ensure trust in a forwarded email?

The ARC-Authentication-Results header captures the original authentication status, the ARC-Message-Signature cryptographically signs the message's state, and the ARC-Seal signs the entire chain of ARC headers. This creates a verifiable history that subsequent receivers can trust.

Is ARC a replacement for SPF, DKIM, or DMARC?

No, ARC is not a replacement. Instead, it works in conjunction with SPF, DKIM, and DMARC to preserve their authentication results across forwarding hops. It allows DMARC to make more accurate decisions for forwarded mail.

What happens if an ARC chain is broken or invalid?

If an ARC chain is broken or invalid, it indicates that the email or its authentication history may have been tampered with. The receiving mail server will then typically revert to evaluating the email based on its current SPF, DKIM, and DMARC results, which might lead to the email being marked as spam or rejected.

What are the three main ARC header fields? - ARC - Email authentication - Knowledge base

An email envelope with a chain link representing ARC headers

Email authentication protocols like SPF, DKIM, and DMARC are crucial for verifying sender identity and preventing spoofing. However, a significant challenge arises when legitimate email forwarding services or mailing lists modify an email's headers or body. These changes can inadvertently break the authentication chain, causing legitimate emails to fail DMARC checks and potentially land in spam folders. This is where the Authenticated Received Chain, or ARC, steps in to preserve valuable authentication results.

ARC is a standard defined in RFC 8617. It allows intermediate mail servers to cryptographically sign the original authentication results and the message's state before any modifications occur. This creates a chain of custody, ensuring that subsequent receivers can validate the email's authenticity even if it passes through multiple hops or is altered. Think of it as a tamper-evident seal that allows the recipient server to trust the historical authentication decisions of previous servers in the relay path.

The ARC protocol introduces three primary header fields that work in conjunction to achieve this transparency and preserve authentication results. Understanding these headers is key to grasping how ARC contributes to improved email deliverability and robust DMARC enforcement, particularly in complex email routing scenarios.

The ARC-Authentication-Results header

ARC-Authentication-Results (AAR)

The ARC-Authentication-Results header, often abbreviated as AAR, serves as a snapshot of the original Authentication-Results header that a receiving mail server generated upon initial receipt of the email. Before any forwarding or mailing list processing occurs, an ARC-enabled intermediary creates this header to capture the authentication outcomes of SPF, DKIM, and DMARC at that specific point in the email's journey. This is crucial because subsequent intermediaries might alter the message in ways that would invalidate these initial results if not preserved.

The AAR header contains various authentication methods and their corresponding results. For instance, it might show SPF pass, DKIM pass, and the DMARC policy decision at the time the intermediary received the message. This archived version of the authentication results is a fundamental building block of the ARC 'chain' concept, allowing subsequent receivers to see what the authentication status was before any changes.

Example ARC-Authentication-Results headeremail

ARC-Authentication-Results: i=1; mx.example.com;
  spf=pass (sender IP is 192.0.2.1) smtp.mailfrom=sender.com;
  dkim=pass (signature was verified) header.d=sender.com;
  dmarc=pass action=none header.from=sender.com

The ARC-Message-Signature header

ARC-Message-Signature (AMS)

The ARC-Message-Signature header, or AMS, is similar to a DKIM signature. It provides integrity protection for specific elements of the email, including the ARC-Authentication-Results header, other key email headers, and the message body. When an ARC-enabled mail server processes an email, it creates this signature over these components, ensuring that they haven't been tampered with since the signature was applied. This is why it's considered a cryptographically signed copy of the message's state.

The AMS header includes tags such as s= (selector), d= (domain), and h= (signed header fields), which contains the list of signed header fields. These fields specify which parts of the email were signed, allowing a recipient to verify the signature against the current message content. This ensures that any subsequent modifications can be detected, helping to prevent malicious alterations while still allowing for legitimate forwarding changes. The ARC-Message-Signature header is used to sign all relevant parts of the message.

It's important to understand that the AMS header is generated by each ARC-enabled hop, and each new hop adds its own AMS to the email. This creates a chain of signatures that reflects the email's journey. If any part of the signed message is altered between hops, the AMS signature will fail validation, indicating potential tampering.

The ARC-Seal header

ARC-Seal (AS)

The ARC-Seal header, or AS, is the final component that binds the entire ARC chain together. Its purpose is to cryptographically sign the combination of the ARC-Authentication-Results header, the ARC-Message-Signature header, and any previous ARC-Seal headers in the chain. This creates a sequential, verifiable record of all the ARC headers added by previous intermediaries. Essentially, the purpose of the ARC-Seal header is to ensure the integrity of the entire authentication history.

Each ARC-enabled server in the email's path adds a new ARC-Seal header. This new seal includes a signature over the combined previous ARC headers. Key tags within the ARC-Seal header are i= (instance number, indicating the position in the chain), s= (selector), and d= (domain). When a receiving server validates an ARC chain, it checks each ARC-Seal, starting from the newest, to ensure that the chain has not been broken or tampered with. The ARC header field indicates chain validation status using the 'cv=' tag.

Chain of custody: The sequential nature of the ARC-Seal allows a recipient mail server to verify the entire history of authentication results, even through multiple forwarding hops.
Trust preservation: If the ARC chain is valid, the final receiving server can trust the authentication decisions made by previous servers, even if changes to the email would normally cause SPF or DKIM to fail.
Anti-tampering: Any unauthorized modification to the ARC headers or the message content after a seal is applied will invalidate the seal, signaling potential malicious activity.

The combined power of ARC headers

How the three headers work together

These three headers form a robust system for preserving email authentication. When an email is forwarded or processed by a mailing list, an ARC-enabled intermediary takes the following steps:

Captures results: It first evaluates the email using SPF, DKIM, and DMARC and then creates an ARC-Authentication-Results header that records these findings.
Signs the message: Next, it generates an ARC-Message-Signature by signing relevant parts of the email, including the newly added AAR header and other key content. This signature provides cryptographic proof of the message's state at that point.
Seals the chain: Finally, an ARC-Seal is created, which signs all previous ARC headers (any existing Seals, AMS, and AAR). This seal acts as a cryptographic lock on the entire authentication history up to that point.

When a subsequent mail server receives the email, it can validate the ARC chain. If the chain is intact and valid, the receiver can then use the historical authentication results from the ARC-Authentication-Results headers to inform its DMARC policy decision. This prevents legitimate emails from failing DMARC due to benign modifications made during transit, a common issue for mailing lists and forwarders.

Without ARC

Legitimate forwarded emails often fail DMARC checks because their headers (for SPF) or body (for DKIM) are altered during transit. This leads to increased spam filtering for genuine mail.

Impact

Email goes to spam: Recipient servers mark legitimately forwarded emails as suspicious, often placing them in the spam folder or rejecting them outright.
Loss of legitimate mail: Users miss important messages, harming communication and potentially business operations.

With ARC

ARC preserves the original authentication results through cryptographic seals, allowing recipient servers to trust the chain of custody and validate the email's authenticity despite modifications.

Impact

Improved deliverability: Legitimate forwarded emails are more likely to pass DMARC and reach the inbox.
Enhanced security: The cryptographic chain helps detect tampering, adding another layer of security against spoofing.

Interconnected gears symbolizing the three ARC headers working together

The importance of ARC

In essence, ARC allows DMARC to function more effectively in the real world where email often undergoes legitimate transformations. By providing a verifiable history of authentication results, ARC helps prevent false DMARC failures, which in turn contributes to better email deliverability and a more secure email ecosystem. This is especially vital for organizations that rely on third-party services, mailing lists, or forwarding rules.

Implementing DMARC and monitoring its performance, including ARC data, is a critical step for any organization focused on email security and deliverability. Platforms like Suped offer comprehensive DMARC monitoring and reporting, providing insights into ARC validation statuses and helping you fine-tune your email authentication policies. Our AI-powered recommendations help you to quickly identify and resolve issues, ensuring your legitimate emails reach the inbox.

By understanding these three key ARC header fields, you gain a deeper appreciation for how modern email authentication adapts to the complexities of email routing, ensuring that legitimate emails are not mistakenly flagged as malicious and that your DMARC policies remain effective.