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 (email@example.com) from her personal email account (firstname.lastname@example.org) 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 (email@example.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 firstname.lastname@example.org 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. email@example.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.
When an email arrives at any intermediary server, authentications are performed and the following three steps are executed:
- The server adds the ARC Authentication Results (AAR) field, featuring all the results, into a new field and prefixes it to the email.
- 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.
- 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.
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):
ARC-Authentication-Results: i=1; mx.google.com; dkim=pass firstname.lastname@example.org header.s=20161025 header.b="ec/yg4BT"; spf=pass (google.com: domain of email@example.com designates 184.108.40.206 as permitted sender) firstname.lastname@example.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com ARC-Message-Signature: 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== ARC-Seal: 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: <email@example.com> Received: from example.org (example.org [220.127.116.11]) by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207 for <firstname.lastname@example.org>; Thu, 14 Jan 2015 15:02:40 -0800 (PST) Received: from segv.d1.example (segv.d1.example [18.104.22.168]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for <email@example.com>; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from firstname.lastname@example.org) 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 email@example.com) Received: from mail-ob0-f188.google.example (mail-ob0-f188.google.example [22.214.171.124]) by clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268 for <firstname.lastname@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 email@example.com; dkim=fail (512-bit key) firstname.lastname@example.org; 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 email@example.com; dkim=fail (512-bit key) firstname.lastname@example.org; 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 email@example.com; dkim=fail (512-bit key) firstname.lastname@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 email@example.com; dkim=pass (512-bit key) firstname.lastname@example.org; dmarc=pass
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.