What is Authenticated Received Chain (ARC)

Introduction to ARC

As the digital landscape becomes increasingly complex, email security has emerged as a critical concern for individuals, businesses, and organizations. The influx of sophisticated phishing attacks and email spoofing has prompted the need for robust mechanisms to authenticate and validate email messages. Authenticated Received Chain (ARC), introduced in 2019 is an essential protocol designed to enhance email security by ensuring the legitimacy of emails as they traverse through various mail servers. It complements existing protocols like SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance), offering an additional layer of trust in email communications.

Why ARC is Necessary

In typical email scenarios, legitimate emails may pass through multiple intermediate entities such as mailing lists, forwarders, or gateways, each of which can modify headers or message content. These modifications can disrupt standard authentication processes, causing challenges with SPF, DKIM, and DMARC checks, and potentially leading to false rejections of legitimate emails. ARC addresses these concerns by creating an “authenticated received chain” that preserves the original authentication results even as the email passes through these intermediaries. By maintaining the integrity of the authentication status through each hop, ARC helps ensure that the original sender’s authentication can still be trusted by the final recipient, reducing the chances of legitimate emails being falsely flagged or rejected.

ARC Supports SPF, DKIM, and DMARC

• SPF (Sender Policy Framework): SPF helps verify that the sending IP address has permission to send emails on behalf of the domain. However, SPF validation can fail when emails are forwarded, as the forwarding server’s IP may not be authorized. ARC overcomes this limitation by allowing the forwarding server to include its authentication check results for the original sender, thereby maintaining trust through information relayed in the ARC header.
• DKIM (DomainKeys Identified Mail): While DKIM provides a mechanism for ensuring that an email has not been tampered with, changes such as message handling by mailing lists can inadvertently break DKIM signatures. ARC ensures that even if DKIM signatures are altered en route, the original signature’s validity is preserved and verifiable by subsequent servers.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): DMARC builds on SPF and DKIM, using their results to determine an email’s authenticity and define policies for handling suspicious emails. ARC augments DMARC by facilitating consistent authentication outcomes, ensuring that policy decisions based on the original header information remain viable despite intermediate alterations.

ARC

ARC is a vital advancement in the realm of email security, bridging gaps in conventional authentication systems and fostering more reliable email communications. By capturing and protecting the authentication chain, ARC bolsters the efficacy of SPF, DKIM, and DMARC, addressing the challenges posed by forwarding and intermediary mail processing. As detailed in RFC 8617, ARC contributes significantly to the reliability of email security systems, ensuring that important communications are delivered with integrity and trust intact. The ARC system consists of three primary components, each playing a crucial role in maintaining the integrity and authenticity of the email:

1. ARC-Seal:

• Purpose: The ARC-Seal is a cryptographic signature applied by an intermediary email server to the email header as it processes the message. It serves to confirm that the intermediary handled the email and that the ARC-Authentication-Results and ARC-Message-Signature headers are intact and unaltered.
• Functionality: By applying an ARC-Seal, each intermediary attests to the authenticity of the message and its associated metadata as it was received. The seal includes the cryptographic signature, the domain of the intermediary, a sequence number indicating the ARC set’s position in the chain, and a signed hash covering selected headers and the ARC-Message-Signature.
• Significance: The ARC-Seal ensures that the chain of custody is preserved through multiple email hops. Each intermediary in the chain signs the previous intermediary’s ARC set, thereby providing a chained assurance of authenticity back to the originating sender.

2. ARC-Message-Signature:

• Purpose: The ARC-Message-Signature is similar to the DKIM (DomainKeys Identified Mail) signature. It verifies the integrity of the email content by creating a signature over specified portions of the email, including selected headers and the body.
• Functionality: When an intermediary receives and processes a message, it creates an ARC-Message-Signature that captures the state of the message at that point in the chain. This allows downstream servers to confirm that the message has not been altered by verifying the signature against the same sections of the message.
• Significance: This component ensures the specific parts of the email content remain unchanged as it traverses through various intermediaries. By comparing the message signature, recipients can detect unauthorized alterations and maintain trust in the content’s integrity.

3. ARC-Authentication-Results:

• Purpose: This component records the results of the authentication evaluations performed by the intermediary. It documents the findings of common email authentication methods like SPF (Sender Policy Framework), DKIM, and DMARC (Domain-based Message Authentication, Reporting & Conformance).
• Functionality: After evaluating the incoming email through various authentication checks, the intermediary server adds an ARC-Authentication-Results header. This header summarizes the authentication outcomes, such as ‘pass’, ‘fail’, or ‘neutral’, offering subsequent recipients transparency about the email’s authentication status at each hop.
• Significance: The ARC-Authentication-Results provides crucial information to downstream servers and receiving inboxes about the authentication state of the email when processed by each intermediary. This transparency helps preserve the original authentication meaning across multiple hops, aiding in the final decision-making process of accepting or rejecting the email. Together, these components form a comprehensive framework that addresses the challenges faced by legitimate emails being marked as suspicious due to changes brought by intermediary forwarding. The ARC system ensures that the original validation can be trusted despite legitimate alterations, enabling more reliable email authentication and delivery in complex email ecosystems.

Which Companies Support Authenticated Received Chain (ARC).

Leading email inboxes support ARC including:

• ProtonMail
• Microsoft
• Mailgun
• Google
• Yahoo

Furthermore, Google requires ARC headers for email forwarding services.

The Importance of ARC

Authenticated Received Chain (ARC) is important in email environments because it helps maintain the integrity and authentication of emails that are forwarded through various intermediaries, which can often disrupt standard email authentication mechanisms like SPF, DKIM, and DMARC. Here’s a summary of why ARC is vital in such scenarios:

1. Preservation of Authentication Data: ARC preserves authentication results obtained when an email was initially received. This data can be maintained across each hop or forward an email takes, ensuring that the original authentication verdicts are visible to the final receiving server.
2. Preventing False Positives: Email forwarding frequently causes issues with DMARC alignment, leading to legitimate emails being marked as fraudulent or spoofed. By maintaining a chain of verifiable authentication records, ARC helps prevent legitimate messages from being incorrectly labeled as spam or rejected outright.
3. Transparency and Trust: ARC adds a layer of transparency in the email forwarding process. It provides email receivers with additional information about the journey an email took across multiple servers, allowing them to make more informed decisions about the email’s authenticity and trustworthiness.
4. Support for Complex Email Flows: In environments with complex email routing, such as mailing lists and service providers that modify email headers, ARC helps ensure that these modifications don’t invalidate the email’s initial authentication checks, facilitating smoother interactions in these ecosystems.
5. Enhanced Security: By ensuring the integrity of authentication information through each step of the email’s journey, ARC contributes to an overall enhancement of email security. It makes it more difficult for malicious actors to tamper with authentication records unnoticed.
6. Facilitating Compliance: Organizations that rely on outsourced services for email processing or have established complex forwarding rules can use ARC to ensure compliance with authentication standards without disrupting legitimate communications. Overall, ARC is crucial for maintaining reliable email authentication in scenarios where forwarding or intermediary handling might otherwise break standard protocols. It helps secure the email ecosystem against abuse and misclassification of genuine messages.

Why do I need ARC if I have SPF, DKIM, and DMARC?

ARC (Authenticated Received Chain) is an email authentication protocol that complements SPF, DKIM, and DMARC. While SPF specifies authorized sending IPs, DKIM provides a digital signature, and DMARC prevents domain spoofing, these protocols can fail during email forwarding, breaking authentication. ARC addresses this by allowing entities to add authentication results to the email header as it’s forwarded, creating a chain of trust. This ensures accurate email authentication across complex mail routes, improving the deliverability of legitimate emails.

Should I implement ARC in 2024?

If you have correctly implemented SPF, DKIM, and DMARC, and are not experiencing issues with deliverability, you may not need to implement ARC, especially as it is still a young policy compared to SPF, DKIM, and DMARC and still has implementation issues, as well as being classed as an experimental standard. Furthermore, it may be automatically configured for you in some cases. Always be sure to monitor SPF, DKIM, and DMARC reports, which often contain real ARC reports, reported directly from inboxes that you send to.

Configuring Trusted ARC Sealers in Microsoft Defender for Office 365

Authenticated Received Chain (ARC) was invented in 2019, and is still an experimental standard, yet it is possible to white list/allow list email in inboxes such as Microsoft Office 365, by configuring trusted intermediaries by trusting seals from specific domain names. Microsoft 365 can then check the public key of the signature, use it to verify the seal, and check against your list of trusted/whitelisted/allow-listed senders.

Understanding the Importance of ARC in Email Security and Authentication

The Authenticated Received Chain (ARC) is necessary to tackle issues related to the forwarding of emails, specifically concerning the preservation of authentication results. When an email passes through multiple intermediaries, such as mailing lists or forwarding services, the original authentication information can be lost or altered, causing challenges for receiving servers in determining the legitimacy of the message. ARC addresses this challenge by allowing each intermediary server to sign its authentication results and preserve the chain of custody. This helps the final recipient verify whether the email’s authentication results can be trusted even if it has been forwarded, thus maintaining the integrity and security of email communication.