Authenticated Received Chain Explained

The global adoption of email authentication methods made phishing a lot more difficult. It also improved the deliverability for many senders and gave ISPs the tools to easily differentiate legitimate and fraudulent emails. It has now come to light, however, that this system is not always fool-proof. 

Since no two methods for sending email are identical, DMARC checks sometimes return false negatives for perfectly legitimate emails. To prevent this from happening, Authenticated Received Chain (ARC) is now in common use. In this article, we’ll discuss its role, components, and various situations when it is particularly useful.

What is ARC?

Authenticated Received Chain is an authentication record sent with an email. It tells each email server encountered about the past authentications an email has gone through, and the entities that had performed these checks. Because of that, it’s often referred to as a “chain of custody”.

Through this process, ARC is able to preserve the authentication results and get an email ‘approved’, even if either of these checks fails at the final hurdle. While it’s not error-proof, it’s efficient at delivering legitimate emails to inboxes and is now in common use.

ARC consists of three components:

• ARC-Authentication-Results header – the core part of ARC, containing all previous authentication results, including SPF, DKIM, and DMARC
• ARC-Signature – the signature resembling the DKIM signature, which includes the headers and body of a message
• ARC-Seal – both of the previous components, again in the form of a DKIM-style signature

When is ARC useful?

To understand the role of ARC, let’s first have a recap of common authentication methods:

SPF lets you specify the IPs that are authorized to send emails on your behalf. When a check is performed, the sender’s IP is verified against the authorized list. If there’s no match, SPF fails.

DKIM is a certification sent with an email. It includes hashed headers and the body of your message, which is decrypted upon arrival and verified against the message received. If the two messages don’t match, indicating that an email was modified on the way, DKIM fails.

DMARC requires all checks present (SPF, DKIM, or both) to pass. It also adds another alignment test on top of that and allows the user to decide how failed emails should be handled.

Authentication method issues

There are various email services, such as mailing lists or forwarding tools, that can cause certain complications when authenticating emails. Let’s look at the following example:

Kate is a big fan of snooker and did not hesitate to join a mailing list for snooker fans in her town. She reads a lot about her favorite sport, and loves sharing the latest headlines with the three other people on the mailing list. 

She does so by emailing the group address (kansascity-snooker@coolmailinggroup.com) from her personal email account (kate@gmail.com) and authenticating her emails using SPF and DKIM.  She would have authorized her address beforehand on Gmail, to send on her behalf (this was most likely a default setting).

When she sends an email, an SPF check is performed and her sending address (kate@gmail.com) is checked against the authorized list. Of course, it matches. The same things happen on each following check. The final emails to group members are sent; however, not from Kate, but from the group itself. As kansascity-snooker@coolmailinggroup.com wasn’t SPF authorized, the SPF check fails. If DMARC policy was set to ‘reject’, an email would probably be discarded.

The story doesn’t end here. Kate sends each of her stories to her friend overseas as well. The friend in question, let’s call her Julia, receives emails directly to her inbox. kate@gmail.com always shows as the sender so SPF is not an issue. 

Julia, however, uses some forwarding service to receive emails in her inbox (it was advertised as an extremely secure solution). The service indeed scans carefully through each email, looking for potential threats. When it’s finished, it adds “Email checked and verified by XYZ” in the message footer. A bit annoying but, well, safety first.

When a message arrives on the final server, a DKIM check is performed. And it fails miserably because the message received is different than what was sent from Kate’s computer. Consequently, DMARC also fails, and the message is probably discarded.

Authenticated Received Chain would attempt to prevent both situations. It would tell the ISP something along the lines of, “Hey, what’s up? FYI, this email was fine on the last 3 checks, done by X, Y, and Z, both for SPF and DKIM. Let it go.” And with a high dose of probability, the server would listen and approve the message.

How does Authenticated Received Chain work?

In reality, ARC wouldn’t exactly start its message with “Hey, what’s up?”. Instead, it would stick to the three-components structure that we mentioned earlier. 

But, before we get to the example, let’s briefly discuss how ARC is signed and validated.

Signing ARC

When an email arrives at any intermediary server, authentications are performed and the following three steps are executed:

1. The server adds the ARC Authentication Results (AAR) field, featuring all the results, into a new field and prefixes it to the email.
2. Then, it formulates the ARC Message Signature (AMS) for the email (also featuring the AAR from the previous step) and prefixes it to the email.
3. Finally, the server builds the ARC Seal (AS) for the previously generated ARC Seal headers and prefixes it to the email.

Each time a new ARC is added, a new instance is created and prefixed along with each component. These start from “i=1”, and follow with “i=2”, “i=3”, etc. for each intermediary server.

Validating ARC

At the final stage of an email’s journey to an inbox, ARC is finally validated. 

• First, the server verifies the chain of ARC Seal headers – checks that there are no missing entries, if all seals state that the previous entries are valid, etc.
• Then, it validates the latest AMS (the one with the highest instance number).

If everything checks out and the authentication results along the way were positive, an email is very likely to land in the recipient’s inbox.

Example of ARC

Let’s look at the example of ARC that was generated for a simple email sent between two Gmail accounts (that passed all the underlying tests):

<strong>ARC-Authentication-Results</strong>: i=1; mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20161025 header.b="ec/yg4BT";
       spf=pass (google.com: domain of kate@gmail.com designates 209.86.120.51 as permitted sender) smtp.mailfrom=kate@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
<strong>ARC-Message-Signature</strong>: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=to:subject:message-id:date:from:mime-version:dkim-signature;
        bh=BTxSUCASSXq89dwEZAElzbcuKVUwPRSErwJCLGWqxM8=;
        b=X7PX7dl3NzGKLDzDo21ztS5+u94wTJIko/QLX+/ujkp6PxZvBghTEbH0dy8pFAUiwT
         Ik7ZaT6/KIxoy/N+8TTQ0ahrjOz3xDrvfPekHKiKGiAsKfrNSNoMUlsiRv0m2qo9w0XE
         /+HjCK3PZNBRsjw2mXLS5zP9Co46K7wzut8L8yNpcet7cFmqCu+q5mzr6xhRhex3K5Sf
         HfTJj0GVyMs2lsjthofJGq6I6dMdd38nBDIrQ2yOvcJeOUGuicl1mDrRVBbFUdu7hwEh
         IdkrfGxdAd/I88SowEHvfn9Ib1BqBhzQFS0eqGrco3loVcAjkWgNeDDQcbldJjIiX1pq
         /ujQ==
<strong>ARC-Seal</strong>: i=1; a=rsa-sha256; t=1611068302; cv=none;
        d=google.com; s=arc-20160816;
        b=pRj/xo1gm56C5GxPebDvFtAl4Da+LhlkNqt2//vJlw/cGgNDwDbneF/kZR8E/UXG4J
         GxjRoAwYSpupaTDq/KTJmgtVHcDLfpeE7Y1w6FpyY995nNfxetM7NYVGdeO9CFl9sEOh
         7XQPUtSBTU6y8gsBc0aQRtuoVQlpFNykvhs2OX+86ub0kTG3K2Ih7jgCfaaKfNSF//D6
         jTUDlL5wgqEHRI1rJM4AnHp//8L5dCsJ6HNYoAeo8qmViQwaFOOa7tMjxUfqQC3Xfp+v
         vwgWymKnQeG615zpncaccIk0iYUV6bzraw2e7hWpQXbtKHXScXXLmY68JuTp8s8Ento2
         5bzw==

The syntax here is very similar to DKIM Syntax. The main differences are the ‘i’ (instance) tag that’s not present in DKIM, as well as DKIM’s ‘bh (message body)’ tag that didn’t make it to ARC.

The important part unknown from DKIM is, however, the ARC-specific ‘cv’ tag. ‘cv’ stands for Chain Validation Status and is basically the representation of the state of ARC that’s passed on to the following servers. It can have three possible values:

• None – no ARC sent with a message prior to its arrival. It’s a typical behavior if a message is sent and received by the same Mail Transfer Agent (MTA) or Mail Submission Agent (MSA). In our case, it was an internal Gmail transfer, thus no need for ARC.
• Pass – a message contains ARC and its validations succeeded.
• Fail – a message contains ARC and its validations failed.

Finally, let’s look at a more complex ARC, prefixed to an email that went through several intermediaries and failed an authentication here and there. It was originally featured in the official ARC specification.

Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
    by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
    for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
    by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
    for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
Received: from [2001:DB8::1A] (w-x-y-z.dsl.static.isp.example [w.x.y.z])
    (authenticated bits=0)
    by segv.d1.example with ESMTP id t0FN4a8O084569;
    Thu, 14 Jan 2015 15:00:01 -0800 (PST)
    (envelope-from jqd@d1.example)
Received: from mail-ob0-f188.google.example
    (mail-ob0-f188.google.example [208.69.40.157]) by
    clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268
    for <fmartin@example.org>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
        clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
        +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
        clochette.example.org; h=message-id:date:from:to:subject; s=
        clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
        LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
        K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
    ams.2.gmail.example=pass, as.1.lists.example.org=pass,
    ams.1.lists.example.org=fail (message has been altered))
Authentication-Results: clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
    ams.2.gmail.example=pass, as.1.lists.example.org=pass,
    ams.1.lists.example.org=fail (message has been altered))
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t=
        12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE
        8jjLXWpRNuh81yqnT1/jHn086RwezGw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
        gmail.example; h=message-id:date:from:to:subject; s=20120806; t=
        12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44  cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA59WSqI9s9DfyKDfWg==
ARC-Authentication-Results: i=2; gmail.example; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@example.org; dmarc=fail; arc=pass
    (as.1.lists.example.org=pass, ams.1.lists.example.org=pass)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists;
         t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/
        lHxLi21pxu347isLSuNtvIagIvAQna9a5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
        lists.example.org; h=message-id:date:from:to:subject; s=
        dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL
        Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y
        yHgcIwGHhSc/4+ewYqHMWDnuFxiQ==
ARC-Authentication-Results: i=1; lists.example.org; spf=pass
    smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key)
    header.i=@d1.example; dmarc=pass

Wrapping up

It’s important to note that sending ARC with your messages doesn’t guarantee delivery. At the end of the day, even if all things check out, it’s the email server that makes the final decision. And authentications are just one of the many factors affecting email deliverability.

All in all, ARC is an important addition to an already impressive mix of authentication methods. If you’re having trouble authenticating with any, check out our dedicated guides, and we’ll see you around.