What is Authenticated Received Chain (ARC)?


The advent of DMARC (Domain-based Message Authentication Reporting and Conformance) enables businesses to thwart email spoofing attacks and improve email deliverability. Not only can a DMARC implementation with a p=reject policy block all unauthorized emails via a domain, but also it delivers 100% legitimate emails to the user's inbox.

Right? Well, not really. At least not 100%, when the email goes through an indirect mailflow.

Indirect mailflow

What is an indirect mailflow? Here is a quote from ARC Specification for Email:

When an email sender or Internet domain owner uses email authentication to make it easier to detect fraudsters sending messages that impersonate their domain, some services like mailing lists or account forwarding may cause legitimate messages to not pass those mechanisms, and such messages might not be delivered. These services may be referred to as intermediaries because they receive a message, potentially make some changes to it, and then send it on to one or more other destinations. This kind of email traffic may be referred to as an indirect mailflow.

Simply put, when an email routes through intermediary servers before it's delivered at the final destination, it's an indirect mailflow; whereas an email is delivered without going through any intermediary, it's a direct mailflow.

So how does an indirect mailflow affects the deliverability of legitimate emails? Well, before an email leaves an intermediary, the intermediary could alter the subject or content of the email, which causes DKIM validation to fail. For example, a forwarding service might prepend "FW: " to the subject of the email. What's more, since the intermediary's IP address is different than the source email server, which might cause SPF validation to fail, if the intermediary's IP address is not allowed in the SPF record. Therefore, when both DKIM and SPF fail to authenticate, DMARC authentication fails too.

Okay. So how can we fix this problem? Authenticated Received Chain (ARC) is designed specifically to address this issue. Per ARC Specification for Email:

ARC preserves email authentication results across subsequent intermediaries (“hops”) that may modify the message, and thus would cause email authentication measures to fail to verify when that message reaches its final destination. But if an ARC chain were present and validated, a receiver who would otherwise discard the messages might choose to evaluate the ARC results and make an exception, allowing legitimate messages from these indirect mailflows to be delivered.

That is, despite an indirect mailflow which causes an email to fail DMARC authentication, an ARC-enabled server can still check if there is any preserved positive email authentication result available, and if so, the email is considered authenticated regardless of the DMARC authentication failure.

Example of indirect mailflow

The following is an example of an indirect mailflow:


In the scenario illustrated above, the emails were sent from one of the email hosts for acmecorp.com, to a mailbox on intermediary.com hosted by Gmail, then forwarded by that mailbox to another Gmail account, and Gmail sent the DMARC reports to DMARCLY.

That's why you see arc=pass in the screenshot, indicating an indirect mailflow. And SPF Domain and DKIM Domain were intermediary.com as these messages were forwarded from an intermediary.com mailbox.

In such a scenario, the DMARC authentication result was overridden by arc=pass, the messages were considered legitimate, and you don't need to take any action on your side.

Status of Authenticated Received Chain (ARC)

The Authenticated Received Chain (ARC) specification has been published by the IETF as RFC 8617 in July 2019. Implementation of the protocol will speed up across the industry.

Products with ARC support:

  • Halon MTA: a Mail Transfer Agent (MTA) designed “for large-scale email services.”
  • MailerQ: an MTA designed to “send large volumes of email with maximum control at unparalleled speed.”

According to Microsoft, "ARC is under development here at Microsoft."

Services with ARC support:

  • Gmail: a free, advertising-supported email service developed by Google;
  • Google Workspace, formerly known as G Suite: a brand of cloud computing, productivity and collaboration tools, software and products developed by Google;
  • Google Groups: a service from Google that provides discussion groups for people sharing common interests.

Mailing List Managers with ARC support:

  • Mailman: a free MLM “for managing electronic mail discussion and e-newsletter lists.”
  • Sympa: an open source mailing list manager. It provides advanced features with a rich and secure web interface.

What should you do as a brand owner?

As a brand owner, domain administrator, or marketer who is responsible for managing your domain reputation/email deliverability, the good news is: you don't need to anything. No policy to publish. No DNS record to update. The ARC implementation happens on the server side, and it's transparent to email senders.

Previous Post Next Post

 Protect Business Email & Improve Email Deliverability

Get a 14 day trial. No credit card required.

Create Account