What is ARC, or Authenticated Received Chain?

Internally, and through our support channels, the term ARC, or Authenticated Received Chain, has been coming up more recently. While this new standard is not something you need to implement, I’d like to describe what it is, and what it means to you as a sender. 

Learn more about transactional email best practices.

What is ARC? #

ARC, or Authenticated Received Chain, is a standard created in 2016 to help improve how DKIM and SPF results are passed from one mail server to the next during forwarding. When messages are passed to intermediaries like mailing lists or email account forwarding, DKIM and SPF can break. ARC aims to fix this. The arc-spec site sums it up well:

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.

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.

Let’s look at this using an example message sent from Postmark to Gmail. You have a custom Return-Path setup along with DKIM, and you have a DMARC policy in DNS (If you don’t, go take care of that!). Any emails sent from Postmark will be authenticated and “fully aligned” when they land at ISPs like Gmail or Outlook. Here is an example of what the headers might look like for this message:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@postmarkapp.com header.s=20130519032151.pm header.b=SaTOwM7u;
       dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
       spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.124 as permitted sender)

Now, let’s assume that your customer automatically forwards their emails to a Yahoo account. When it lands on Yahoo’s servers, this message will now fail DMARC SPF alignment because the Return-Path headers have changed. In addition, it is likely DKIM will fail as well since the message content has changed. This happens because the new sender is Gmail, not Postmark, who you verified as an approved sender in SPF.

How does ARC help? #

If you use our DMARC tool, you probably already know that forwarding causes a lot of DMARC failures. We get quite a bit of support and confusion around forwarding for this reason. 

With ARC, the authentication results are now passed down on each hop between mail servers. For instance, when it lands on Gmail, they insert an Authentication-Results header that defines the results of SPF and DKIM. This header is then used when the message is forwarded on to the next mail server, who can use this information to validate the authentication results.

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@postmarkapp.com header.s=20130519032151.pm header.b=SaTOwM7u;
       dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
       spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.124 as permitted sender) smtp.mailfrom=pm_bounces@pmbounces.postmarkapp.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=postmarkapp.com

The header above looks exactly like the Authentication-Results header, except it has “ARC-” in front of it. Let’s assume this message was then forward to Yahoo. Gmail will pass along this ARC-Authentication-Results header to Yahoo, who can then use this information to assume the message is safe. When the message lands on Yahoo’s servers, it includes these headers:

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@postmarkapp.com header.s=20130519032151.pm header.b=SaTOwM7u;
       dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
       spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.124 as permitted sender) smtp.mailfrom=pm_bounces@pmbounces.postmarkapp.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=postmarkapp.com

You may notice that the headers look identical to what was on Gmail. What you can see is Yahoo trusted the results that Gmail provided, and therefore used the previous Auth Results for DKIM, SPF, and DMARC results below.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@postmarkapp.com header.s=20130519032151.pm header.b=SaTOwM7u;
       dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
       spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.124 as permitted sender) smtp.mailfrom=pm_bounces@pmbounces.postmarkapp.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=postmarkapp.com

Since ARC was used, forwarding has not impacted the results of DKIM or SPF. If you used a reject policy for DMARC, this would now pass. 

In addition to the ARC-Authentication-Results headers, you might also discover two new headers: ARC-Seal and ARC-Message-Signature. They look something like this:

ARC-Seal: i=1; a=rsa-sha256; t=1504715872; cv=none;
        d=google.com; s=arc-20160816;
        b=Nz9pPmKDifg+wmSdwCnUjXvG9jG9WFoF6fghYY1QdGolnG/TZoGeuJHkzDl8KQyVtt
         xsTqAtv0sJQcqtGONMLw6K/lPRurwu2PTZLRnPafig2TOAXI+0/qFic8pmRnPrWP+0r4
         N838/B8VMHu1S8Q+2twlVux74yPUwLvjjm9bP5fdKoek0n9yc5Eqr03OPYKxp7g6mgrQ
         0dC5MMklg0nuorbN9dqa34NHtCORGqOGhHdEhbYSQ7UBrljWB2p3E3RZCOXLt6pdEDcu
         jMMc4G2FLySqP5WjG2Ru4OiST6buvygpGOVFJusIEOr+al0Iv610kx10pxUimQrZtSRL
         8HPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:subject📅to:from:mime-version
         :feedback-id:message-id:dkim-signature:dkim-signature
         :arc-authentication-results;
        bh=F3xWEof0wbMYYQQTcMCgWyziErnPAP8h+MmTpoMWTmw=;
        b=drx3lVSLNBLsydWX+t91fFq4LLi7Vf17nU8uxQT0h5P1hbruNRGp+GPTUClVG77wL2
         aShoNrhMV/wDCZEDu6YUN9EC23WAfOfQk6ltZQ0UiUb47tgxAJNrDf+0PR7FWcveZt6X
         CJNqAnOMd8y2asOg/ljIdhjG8TGZt5egORiRE1Nad3JKgXrNiBy3Oi/Epe8GKhQTMulw
         cnS4pp381LHCccsBAJOxVjqIs7D+3EeNTYp4myl5DC8A8kEN3z/gS9S0PpVV0Pyr0s9n
         klXHbKc+hGDjiFXyYIgmqz7GlSfY0sOwQ2xP3b3PkMtIUuWcqBPHjuLK/u51qDIr/2Kf
         pOKA==

During each hop, there is a bit of trust (or assumed trust) that providers must have in the ARC results that are passed along. These two headers allow the ARC chain to be validated as it is passed along.

What can you do about it? #

For you, our customer, there is not much you can do. ARC is implemented by email receivers and ISPs. In most cases providers like Gmail, AOL, etc will implement ARC over time. 

Once enough ISPs support ARC your DMARC reports will start to look much better, with less failures resulting from forwarding. At the moment, both AOL and Gmail support ARC, and we are expecting many more to follow. If you manage an email server, have a look at the ARC Resources page for implementation.