Introduction

Authenticated Received Chain (ARC) is an email authentication protocol designed to address limitations in the existing email authentication landscape, particularly when forwarding emails. ARC allows the verification of email authentication results even when intermediaries modify the message. This blog post delves into the pros, cons, advantages, implementation limitations, and usage scenarios of ARC.

What is ARC?

ARC, short for Authenticated Received Chain, is an email authentication mechanism that works alongside existing protocols like SPF, DKIM, and DMARC. It was introduced to solve the problem of email authentication failures when messages are forwarded through intermediate systems, such as mailing lists or third-party forwarders.

ARC adds a set of headers to the email that records the authentication results from each step in the email’s journey. These headers help the final recipient verify the message’s authenticity despite changes made during transit.

How ARC Works

The introduction of ARC brought the email world three new mail headers:

• ARC-Authentication-Results (AAR): Combination of an instance number (i) and the results of the SPF, DKIM, and DMARC validation.
• ARC-Seal (AS): Combination of an instance number (i), a DKIM-like signature of the previous ARC-Seal headers, and the validity of the prior ARC entries.
• ARC-Message-Signature (AMS): Combination of an instance number (i) and a DKIM-like signature of the entire message except for the ARC-Seal headers.

Upon receipt of email, the receiving mail server applies those three ARC headers to the message. This way, if the message is forwarded or relayed, the original authentication results are preserved. (i.e., if your business sends an email that then gets forwarded three times, these headers preserve the original authentication as without them, the message will fail DKIM.)

When a mail server forwards an ARC-authenticated email, it performs the below functions to preserve the original results:

1. Copies the “Authentication-Results” field into a new AAR field (starting with i=1) and prepends it to the message.
2. Calculates the AMS for the message (with the AAR) and prepends it to the message.
3. Calculates the AS for the previous ARC-Seal headers and prepends it to the message.

When the recipient server receives the message, it will then try to validate an ARC by performing the following steps:

1. Validates the chain of ARC-Seal headers (no missing entries, all ARC-Seal messages state that the prior ARC entries are valid, etc.).
2. Validates the newest ARC-Message-Signature (based on the instance number).

If the ARC headers have been modified in any way, the message will show a fail for DKIM authentication. If all mail servers involved in the transmission of the message correctly sign and transmit ARC, then the email should preserve the DKIM authentication results.

Pros and Advantages of ARC

• Improved Email Deliverability: By preserving authentication results across intermediaries, ARC enhances the chances of legitimate emails reaching their intended recipients.
• Supports Forwarded Emails: Addresses issues where forwarded emails fail DMARC checks due to changes in the message headers.
• Complementary to Existing Protocols: Works in tandem with SPF, DKIM, and DMARC, ensuring a more robust authentication process.
• Transparency and Traceability: Maintains a chain of authentication results, providing greater transparency into the email’s journey.
• Enhanced Trust: Builds trust among email senders and receivers by demonstrating efforts to authenticate emails effectively.

Cons and Limitations of ARC

• Complexity in Implementation: Setting up ARC requires careful configuration and a good understanding of email authentication mechanisms.
• Limited Adoption: ARC is not universally adopted, meaning its benefits are only realized when both senders and receivers support it.
• Dependence on Intermediaries: ARC’s effectiveness relies on intermediaries correctly implementing and preserving the ARC headers.
• Risk of Misuse: Improper implementation could allow malicious actors to exploit the chain of trust created by ARC.
• Resource Intensive: Verifying ARC headers can introduce additional computational overhead for email servers.

Implementation and Usage of ARC

Implementation Steps

1. Set Up SPF, DKIM, and DMARC: Ensure these protocols are correctly configured as ARC builds upon them.
2. Enable ARC on Your Mail Server: Configure your mail server to add and validate ARC headers. Popular email platforms like Google Workspace and Microsoft 365 support ARC.
3. Test Your Setup: Use email testing tools to verify that ARC headers are being added and validated correctly.

Usage Scenarios

• Email Forwarding: Ensure that forwarded emails pass DMARC checks without being rejected.
• Mailing Lists: Enable mailing lists to maintain email authentication results, preventing false positives for spam.
• Third-Party Email Services: Improve deliverability for emails sent through third-party systems.

Conclusion

ARC is a valuable addition to the email authentication ecosystem, addressing the longstanding issue of forwarded email failures. While its adoption is still growing, its ability to enhance email deliverability and transparency makes it an essential tool for organizations that rely heavily on email communication. By understanding the pros, cons, and implementation nuances of ARC, email administrators can take a significant step toward improving their email security and reliability.