Email Security and Authentication

What Is ARC (Authenticated Received Chain) in Email?

minute read

Post Image

With the email marketing industry projected to surpass $9.5 billion soon, knowing how to keep yourself and your recipients safe when sending messages should be a priority. Enter 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.

The problem with indirect mail flow

To fully understand email 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.

Sender Policy Framework (SPF) and DomainKeys Identified Mail (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, Domain-based Message Authentication, Reporting, and Conformance (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.

What is ARC?

Authenticated Received Chain helps preserve email authentication results and verifies the identity of email intermediaries that forward a message to its final destination. ARC has three main components:

  • ARC Authentication Results header: a header containing email authentication results like SPF, DKIM, and DMARC.
  • ARC Message Signature header: a DKIM-like signature that takes a snapshot of the message header information, including the to, from, subject, and body.
  • ARC Seal header: another DKIM-like signature that includes the ARC Signature and the ARC Authentication Results header information. This ARC Seal has a chain validation tag that looks like this: cv=. This header tag hosts the outcome after evaluating the existing ARC chain. The three possible values are:
    • None: No ARC chain to validate
    • Fail: ARC chain validation failed
    • Pass: ARC chain validation succeeded

How does ARC work?

How does ARC work?

ARC preserves authentication results during the traveling 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. 

What can’t ARC do? 

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 depends on email receivers trusting each other by applying the protocol.

What are the benefits of ARC?

ARC has many advantages for both email users and providers, such as:

  • Increased security: Email service providers can verify whether messages are authentic since ARC detects if someone has tampered with a message. Even if emails somehow bypass other security checks, this additional safety feature lowers the risk of malicious content reaching recipients. With 361.6 billion emails sent every day, knowing that you’re sending and receiving emails safely is critical.
  • Better deliverability: Because of the extra security, ARC helps increase the rate of legitimate emails reaching their destinations instead of being flagged as spam.
  • Improved reporting and troubleshooting: ARC provides in-depth insight into how an email passes through various servers. If a message fails to deliver, it’s much easier to determine where the problem is and troubleshoot it once you’ve pinpointed the source of the issue.

How can ARC help you?

If you’re not sure whether ARC is a good idea for your business, it can be insightful to look into how it can help your business:

  • Forwarding messages: Some senders might have DMARC policies that reject or quarantine forwarded emails. These measures are in place to prevent specific forwarders from changing the content of an email, but they can pose a challenge if you have a set up that automatically forwards messages to another account. ARC allows these messages to be passed on to the next sender. Recipients can then decide whether to override the DMARC policy, depending on the information in the ARC email report.
  • Mailing lists: Members of a mailing list can email all other members by addressing the list itself. In doing so, the message gets forwarded to everyone on the list. However, because forwarding an email to large volumes of recipients can break the SPF, these messages will fail when coming across a DMARC server. Since ARC allows users the option to bypass the DMARC limitations, members of an email list can still receive mass messages.

ARC frequently asked questions

Here are some of the most commonly asked questions about ARC:

  • Can ARC replace other email authentication options? You can’t only use ARC for your email authentication. You must combine it with other authentication methods such as SPF, DKIM, or DMARC. ARC is an additional safety measure, not a primary one.
  • Can someone forge or alter your ARC signature? If you implement ARC security protocols correctly, the chances of someone tampering with it are minimal. However, you need to have solid overall security measures in place so that even if one authentication method fails, another will catch it.
  • Do all email providers use ARC? Not all email providers use ARC, but most of the major email providers do, and it’s becoming increasingly popular with smaller servers as well.

ARC is not a silver-bullet solution

Like any email authentication standard, you cannot rely solely on ARC. It does not prevent malicious actors from managing your ARC Authentication Results or Signatures.

But we are still excited about ARC. It is an important step forward in ensuring that people who receive indirect messages can trace the path of an email, allowing them to make more informed decisions about delivery.

If you want to learn more about how you can improve your email performance, read Validity’s eBook, “The 2024 Email Marketing Pulse: Trends, Challenges, and Opportunities for Email Senders.”

ARC is not a silver-bullet solution