In the realm of email security, ARC (Authenticated Received Chain) is a protocol that plays a pivotal role in preserving email authentication results when an email traverses through multiple servers or “hops”. This blog post will explain how ARC works, using a different example from the one provided above.
How does ARC work?
ARC works by adding new ARC headers to an email, which help validate any legitimate changes made to the message during its journey. If DMARC fails during transit, the recipient mail server can choose to check the ARC result in addition to the DMARC result. In certain scenarios, the server may decide to accept the email by overriding the DMARC fail result.
Let’s illustrate this with an example. Imagine a scenario where Alice, an employee at XYZ Corp, sends an email to her team via a company-wide mailing list. Alice wants to share an important update about an upcoming project.
Here’s what Alice’s outgoing email looks like:
To: Team Mailing List <[email protected]>
From: Alice <[email protected]>
Subject: Important Project Update
Dear Team,
Please note the changes in the project timeline.
Best,
Alice
The team mailing list (@xyzcorp.com) checks authentication when it receives Alice’s email from xyzcorp.com, which has a DMARC policy of p=reject. SPF passes and aligns, DKIM passes and aligns, and the message passes DMARC.
XYZ Corp then records these authentication results by adding an ARC Authentication Results header. Here’s an example of what that header might look like:
spf=pass [email protected];
dkim=pass
dmarc=pass
Next, XYZ Corp adds an ARC Signature, which takes a snapshot of the message header information, including the recipient, sender, subject, and body.
Finally, before sending the message to all the team members on the mailing list, XYZ Corp adds an Authenticated Received Chain Seal. This “seal” locks in the information included in the ARC Signature and the ARC Authentication Results header. Now, XYZ Corp is ready to forward Alice’s email to all the subscribers on the team mailing list.
Bob is one of those subscribers. When receiving the forwarded message, Bob’s email server checks not only the email authentication results (SPF, DKIM, DMARC) but also the ARC Seal when deciding whether to deliver the message to Bob’s inbox.
If everything checks out, Bob will receive the email below:
To: Team Mailing List <[email protected]>
From: Alice <[email protected]>
Subject: [Team Mailing List] Important Project Update
Dear Team,
Please note the changes in the project timeline.
Best,
Alice
If the ARC Seal doesn’t pass, then Bob’s receiving email server can apply the p=reject DMARC policy listed in Alice’s xyzcorp.com domain and reject the message.
The Limitations of ARC
While ARC has been adopted by major mailbox providers like Google, Verizon Media, and Microsoft, it’s important to note that it has its limitations and cannot replace DMARC. For instance, ARC doesn’t provide any information about the reputation or trustworthiness of the sender or the intermediaries. Intermediaries can still add malicious content or remove some (or even all) ARC headers.
The success of ARC largely depends on email receivers trusting each other by applying the protocol. Like any email authentication standard, ARC is not a stand-alone solution. Like DKIM, ARC does not prevent a malicious actor from removing or creating new ARC Authentication Results headers or ARC Signatures.
However, ARC is still a significant step forward in helping receivers of indirect messages trace the path of intermediaries and make a safer, more informed delivery decision. It’s an important tool in the arsenal of email security, and its adoption is likely to grow in the future.
Was this helpful?
0 / 0