What is ARC (Authenticated Receivers Chain)

ARC is a protocol that enhances email authentication and security by allowing receivers to verify the identity and authenticity of senders, even when the messages are forwarded or modified by intermediaries.

What is ARC?

ARC is a protocol that allows email receivers to verify the identity and authenticity of email senders, even when the messages are forwarded or modified by intermediaries. ARC is an extension of the existing email authentication standards, such as SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

How ARC works with SPF

SPF is a standard that allows email senders to specify which IP addresses are authorized to send email on behalf of their domains. Receivers can check the SPF records of the senders' domains, and compare them with the IP addresses of the email servers that delivered the messages. If the IP addresses match, the SPF validation passes; otherwise, it fails.

However, SPF validation can be broken by intermediaries that forward or modify the email, such as mailing lists, forwarding services, or spam filters. These intermediaries may change the IP address of the email server, or the envelope sender of the email, which are used by SPF to verify the sender's identity. As a result, the SPF validation may fail, even if the email is legitimate and authorized by the original sender.

ARC solves this problem by preserving the original SPF validation results in the ARC headers, which are added by each intermediary that handles the email. The ARC headers include the following information:

• The ARC-Seal header, which contains a cryptographic signature of the intermediary, the authentication status of the email, and the position of the intermediary in the ARC chain.
• The ARC-Message-Signature header, which contains a cryptographic signature of the email message, including the headers and the body, by the intermediary.
• The ARC-Authentication-Results header, which contains the authentication results of the email, including the SPF validation results, by the intermediary.

The first intermediary that receives the email from the original sender is called the ARC initiator, and it creates the first set of ARC headers. The subsequent intermediaries that receive the email from other intermediaries are called the ARC validators, and they verify the previous ARC headers, and create new ARC headers. The final receiver of the email is called the ARC terminator, and it verifies the entire ARC chain, and decides whether to trust the email or not.

By using ARC, the receivers can see the original SPF validation results of the email, and the identity and reputation of the intermediaries that forwarded or modified the email. This way, the receivers can make more informed decisions about the legitimacy and trustworthiness of the email, and avoid rejecting or marking as spam legitimate email that failed the SPF validation due to intermediaries.

How ARC works with DKIM

DKIM is a standard that allows email senders to sign their email messages with a cryptographic key, which is associated with their domains. Receivers can check the DKIM signatures of the email messages, and compare them with the public keys of the senders' domains, which are published in the DNS records. If the signatures match, the DKIM validation passes; otherwise, it fails.

However, DKIM validation can also be broken by intermediaries that forward or modify the email, such as mailing lists, forwarding services, or spam filters. These intermediaries may change the email headers or the body, which are used by DKIM to verify the integrity and authenticity of the email. As a result, the DKIM validation may fail, even if the email is legitimate and authorized by the original sender.

ARC solves this problem by preserving the original DKIM validation results in the ARC headers, which are added by each intermediary that handles the email. The ARC headers include the same information as described above for SPF, but also include the DKIM validation results in the ARC-Authentication-Results header.

By using ARC, the receivers can see the original DKIM validation results of the email, and the identity and reputation of the intermediaries that forwarded or modified the email. This way, the receivers can make more informed decisions about the legitimacy and trustworthiness of the email, and avoid rejecting or marking as spam legitimate email that failed the DKIM validation due to intermediaries.

What are the benefits of ARC?

ARC provides several benefits for email senders, receivers, and users, such as:

• It preserves the original authentication results of the email, even if the message is forwarded or modified by mailing lists, forwarding services, or other intermediaries.
• It allows receivers to make more informed decisions about the legitimacy and trustworthiness of the email, based on the ARC chain of custody and the reputation of the intermediaries.
• It reduces the chances of legitimate email being rejected or marked as spam, due to authentication failures caused by intermediaries.
• It improves the visibility and accountability of the email ecosystem, by providing a traceable record of the email journey and the authentication status at each hop.

What are the limitations of ARC?

ARC is not a silver bullet for email authentication and security, and it has some limitations, such as:

• It does not prevent email spoofing or phishing, but rather provides a way to detect and mitigate them.
• It does not guarantee the delivery or acceptance of the email, but rather provides a way to improve the deliverability and reputation of the email.
• It does not replace the existing email authentication standards, but rather complements and enhances them.
• It requires the cooperation and adoption of the email senders, receivers, and intermediaries, to be effective and reliable.

What are some examples of ARC?

ARC is currently supported by some major email providers and platforms, such as Google, Microsoft, Yahoo, Fastmail, and Mail.ru. Some examples of ARC scenarios are:

• An email is sent from a Gmail user to a Yahoo user, who forwards it to another Yahoo user. The forwarded email passes the ARC validation, because Gmail and Yahoo both sign and verify the ARC headers.
• An email is sent from a Mail.ru user to a Fastmail user, who forwards it to a Gmail user. The forwarded email fails the ARC validation, because Mail.ru does not sign the ARC headers, and Gmail cannot verify the original authentication results.
• An email is sent from a Microsoft user to a mailing list hosted by Google Groups, which distributes it to multiple recipients. The distributed email passes the ARC validation, because Microsoft and Google both sign and verify the ARC headers, and the recipients can see the original sender and the mailing list in the ARC chain.

Need Help?