Table of Contents
Ever heard of Authenticated Received Chain (ARC)?
Yes, it’s yet another email acronym to add to your repertoire. We’re here to answer the question, ‘What is ARC in email?’ and explain why it matters.
To fully understand ARC, we must understand the problem it solves.
Let’s talk email authentication. Email authentication is vital to protect senders and subscribers against spoofing and phishing attacks—which are on the rise worldwide.
SPF and DKIM are two primary authentication protocols that help validate incoming mail. However, these protocols contain various weaknesses and don’t provide enough protection for senders and subscribers on their own.
About a decade ago, DMARC was developed to add an additional layer of protection to SPF and DKIM. DMARC allows senders and domain owners to give clear guidelines for receiving email servers on how to treat incoming emails that fail SPF and/or DKIM authentication checks.
One tiny problem with DMARC? It assumes that emails remain totally unchanged throughout the deployment process.
Not all mail passes directly from sender to subscriber. Some services, like mailing lists or account forwarding (also known as intermediaries), receive legitimate messages and might make changes before sending them on. This can result in SPF, DKIM, and DMARC alignment failures. In other words, perfectly legitimate messages may not get delivered.
Email forwarding is a great example to showcase how the original ‘seal’ can be broken on a legitimate email, resulting in alignment failures. In this case, the legitimate message will be treated as if it’s been spoofed and won’t be delivered.
This issue doesn’t affect a huge percentage of the global email volume, but we’re still talking about a considerable number of messages.
Authenticated Received Chain helps preserve email authentication results and verifies the identity of email intermediaries that forward a message on to its final destination. There are three key components to ARC:
ARC preserves authentication results during travelling of the email across different “hops” or servers by inserting new additional ARC headers to validate legitimate changes made to the message. After DMARC fails in transit, the recipient mail server can decide to check the ARC result in addition to the DMARC result. In some cases, the server will decide to accept the email by overriding the DMARC fail result.
Let’s see it in action. Consider an email sent from Tom, a parent at Lee Hill Elementary School, to a mailing list of other parents. Tom wants to tell the group that he’s going to bake cookies for the 7th grade play. Mmm, cookies.
Here’s what Tom’s outgoing email looks like:
To: Parent Mailing List <[email protected]>
From: Tom <[email protected]>
Subject: Cookies for the 7th Grade Play
Dear Parents,
I’m bringing cookies! Hooray.
~ Tom
The parent mailing list (@leehill.edu) checks authentication when it receives Tom’s email from example.com, which has a DMARC policy of p=reject. SPF passes and aligns, DKIM passes and aligns, and the message passes DMARC.
Leehill.edu 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
Then, leehill.edu adds an ARC Signature, which takes a snapshot of the message header information, including who it was sent to, who it’s from, the subject, and the body.
Finally, before sending the message to all the parents on the mailing list, leehill.edu adds an Authenticated Received Chain Seal. As the name implies, “seals” the information included in the ARC Signature and the ARC Authentication Results header. Now, leehill.edu is ready to forward Tom’s email to all the subscribers on the parent mailing list.
Marsha is one of those subscribers. When receiving the forwarded message, Marsha’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 Martha’s inbox.
If everything checks out, Marsha will receive the email below (note the changes to the subject field and the body), and she’ll be in for a tasty surprise:
To: Parent Mailing List <[email protected]>
From: Tom <[email protected]>
Subject: [Parent Mailing List] Cookies for the 7th Grade Play
Dear Parents,
I’m bringing cookies! Hooray.
~ Tom
————-
To unsubscribe, click here.
If the ARC Seal doesn’t pass, then Marsha’s receiving email server can apply the p=reject DMARC policy listed in Tom’s example.com domain and reject the message.
Authenticated Received Chain has already been adopted by major mailbox providers like Google, Verizon Media, and Microsoft, and will likely soon become the standard globally.
But ARC has its limits and can’t replace DMARC. For example, ARC doesn’t provide any information about the reputation or trustworthiness of the sender or the intermediaries. And intermediaries can still add bad content or remove some (or even all) ARC headers.
ARC’s success really 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.
But we are still excited about ARC. It is an important step forward in helping receivers of indirect messages trace the path of intermediaries and make a safer, more informed delivery decision.
For more tips to maximize your email performance, read Validity’s eBook, “Secrets of Best-in-Class Email Senders.”