Microsoft’s Increasing Support for ARC

In 2019, Microsoft included ARC support on their Microsoft 365 Roadmap, stating that “(ARC) is now enabled for Office 365 hosted mailboxes.” But at the time, it was only being used for Microsoft senders, or between Office 365 tenants. In 2022, they expanded this to include third party ARC sealers configured on a per-tenant basis.

Microsoft diagram, email message flow using ARC with Office 365

Diagram courtesy Microsoft Defender for Office 365 Blog

The original announcement described the benefits ARC could bring to the users of Office 365 who receive email that has been processed by intermediaries. These third parties might be outsourced help desk operators, or compliance and archiving solutions, or email security and anti-abuse providers. However the announcement ended with the caution that, at that time, ARC was only being evaluated for messages sent between Microsoft systems and/or customers, and that they “plan to add support for third party signers in the future.”

In June 2022, an article was published on the Microsoft Defender for Office 365 Blog that described ARC and how Office 365 tenants would be able to use a new “Trusted ARC Sealers” feature to identify intermediaries that they were using, whose authentication results – recorded in their ARC seals – should be used if they validated. An associated article (Make a list of trusted ARC Senders to trust legitimate indirect mailflows) described how Microsoft Defender 365 administrators could create a list of Trusted ARC Sealers.

This was a long-awaited development, though introduced rather quietly, and Microsoft deserves credit for helping to advance the utility of ARC for enterprise email users. It would be interesting to see what impact it has had for Office 365 tenants who have populated their Trusted ARC Sealers list since the announcement.

Microsoft “enabled” ARC in Office 365

On October 24th an update was published on the Microsoft 365 Roadmap indicating that “Authenticated Received Chain (ARC) is now enabled for Office 365 hosted mailboxes.”

The rather terse update describes the benefits ARC could bring to the users of Office 365 who receive email that has been handled by intermediaries. But it ends with text that may indicate that, for now, it is only being evaluated for messages sent between Microsoft systems and/or customers. “Initially ARC will only be utilized to verify authentication results within Office 365, but plan to add support for third party signers in the future.”

This link should bring up the entry on the Microsoft 365 Roadmap.

RFC 8617 “The Authenticated Received Chain” Published

The Authenticated Received Chain, or ARC, was published by the IETF RFC Editor on Tuesday, July 9th, 2019 as RFC 8617. The general information page for RFC 8617 can be found here, but there are direct links to HTML, PDF, and text versions available. ARC has been published under the IETF’s Experimental status, which is explained in this section of RFC 2026. This reflects that fact that some fine-tuning is expected after Internet senders and receivers gain experience with the protocol after deploying it widely, and seeing what the operational impacts are.

DMARC.org first publicly announced the ARC protocol in October 2015, and it became an official work item of the IETF DMARC Working Group in June 2016. The specification went to “working group last call” in October 2018, but attention shifted to several related areas that needed clarification. This led to revisions to the header field for authentication status (RFC 8601), and updating SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) to better handle internationalized domain names (RFC 8616).

Version 18 of ARC Specification Published

On October 2nd, the IETF’s DMARC Working Group published version 18 of the ARC specification document, incorporating the changes suggested during the Working Group Last Call (WGLC).  There are many small language changes to clarify concepts or bring usage in line with other IETF documents, such as Email Address Internationalization (EAI).

You can review the changes between the pre- and post-WGLC versions using this link.

Working Group Completes Last Call For ARC Specification

The DMARC Working Group has completed Last Call for the ARC specification. This means that when the final consensus changes are incorporated, the document will be submitted for approval and publication by the IETF. It is possible that the specification might be published before the next IETF meeting in November, though perhaps more likely between then and the following meeting in March 2019.

The ARC specification has been under development by the Internet Engineering Task Force’s (IETF) DMARC Working Group since roughly June 2016. In July, just over two years later, the Working Group reached a milestone known as Working Group Last Call (WGLC). During Last Call the members of the group determine if consensus has been reached on the content of the document in question. If so, any final changes are made to the document and it is submitted to one or more IETF officials known as Area Directors. Upon review they may ask questions or make suggestions, and when satisfied, the document is approved for publication.

The ARC specification grew out of work begun by a group known as OAR in the summer of 2014. OAR refers to a proposed email header named Original Authentication Results, the subject of a draft proposal published in 2012.

OpenARC v0.1.0 has been released

After a long development and testing cycle, alongside refinement of the draft protocol itself, an alpha version of an open source implementation of the ARC protocol has been released. Congratulations to the volunteers from across the globe who contributed to this effort over the years.

ARC allows forwarders and mailing lists to convey message authentication results that would otherwise be lost, which can present challenges to some DMARC adopters. OpenARC v0.1.0 is at https://github.com/trusteddomainproject/OpenARC/releases.

An overview of how the ARC protocol works, and in what situations it would be deployed, is available in the presentation ARC Protocol Overview

New ARC Implementations at IETF 99 Hackathon

An ARC table was organized at the weekend hackathon held before the IETF 99 meeting in Prague this week. ARC is an official work item of the IETF DMARC Working Group, and will be discussed during the working group meeting Thursday morning.

Participants from two different vendors worked on new implementations of ARC, compatible with their software stacks. By the end of the weekend, one of these implementations was able to validated multiple-hop ARC chains, which is perhaps the hardest part of any implementation. And a participant from a third vendor indicated they have made significant progress in developing their own ARC implementation prior to the weekend.

If you compare this to all proprietary and open source implementations known before the hackathon, it will represent a 60% increase in the number of ARC implementations when they are completed. In addition to the implementations mentioned, the weekend included more interoperability testing, bug hunting, patch generation, and pull requests.

Many thanks to all the participants at the hackathon, whether they were in the room or working remotely!

ARC Training at M3AAWG 40 in Lisbon, Portugal

There will be training in configuring ARC-enabled software, and adding ARC support to email infrastructure using open source software, at the 40th general meeting of M3AAWG. This meeting will be held at the Corinthia Hotel in Lisbon, Portugal the week of June 12th. Several members of the ARC community will conduct the tutorial program on Monday, while ARC and related email authentication measures will be the topic of formal and informal discussion during this meeting. For more information about M3AAWG and their members, please refer to the M3AAWG web site.

Status of ARC Presentation Available

At a recent industry conference in San Francisco, a panel presented the current state of ARC implementation and deployment. A version of that presentation is now available for review – you can download it here. As reported yesterday source code and a test suite are available now, AOL and GMail are validating ARC headers in messages they receive, and commercial products are starting to incorporate ARC – in fact, MailerQ from Copernica has already included ARC for a few months.

If you are looking for more technical detail on how the ARC protocol works, view this presentation from October 2016. Or read the current version of the protocol published by the IETF DMARC Working Group.