The authentication of an email allows the recipient to make sure the message is safe and that it comes from the right person. This is possible thanks to systems set up such as DMARC, SPF, DKIM and ARC. I am talking about the latter today, the ARC, which is more than unnecessary in the context of indirect messaging flows, namely when an email goes through several intermediaries. It will then help preserve the authentication results of this mail so that it is validated instead of being rejected.

What the ARC?

ARC, Acronym for Authenticated Received Chain is a new protocol approved in June 2016 and published by the IETF DMARC Group under RFC 8617 in July 2019.

It is possible to define it as a control chain for keeping the original authentication results of an email when it goes through indirect messaging flows (such as a broadcast list or email transfer service for example) Potentially changing the message. Each organization dealing with the message in question can thus, thanks to the ARC protocol, have an overview of the different entities having treated it in the meantime and the evaluation of this authentication at each stage of the same chain. In this way, even the emails transferred, and the broadcast list emails can be validated by the courier services.

The ARC does not work alone because it can only confirm an authentication status accompanying an email. It must therefore be used jointly with systems like DMARC, SPF and DKIM.

How does the ARC protocol work?

How does the ARC protocol work?
When a sender sends its email to a recipient, it is the email server entering the recipient that will receive the message first and validate via the DMARC, SPF and DKIM authentication systems. If this same recipient then transfers the message to one or more other entities, then its outgoing email server will insert ARC headers. In this way, the last entity receives the message will at the same time receive applied authentication systems (DMARC, SPF, DKIM and ARC).

Between the transmitter server and the recipient server, each entity dealing with the message sent can seal it by affixing three headers called “ARC set”, creating in this way a kind of string of confidence signatures. Each of these buckets contains the authentication information when the mail is received by a third party. It is the consolidation of all these seals that constitute the ARC.

The three “ARC set” are :

  • Arc-Authentication-Results, the authentication status in which the original message is received (DMARC, SPF and DKIM).
  • Arc-Message-Signature, namely the signature of type DKIM of the message to the shipment.
  • Arc-Seal, the DKIM signature of the arc chain.

Why implement ARC?

When a sender or domain owner uses an e-mail authentication protocol, some intermediate services (such as broadcast lists or email transfers) can cause a blockage of the message. Even if it is perfectly legitimate, it might not be delivered to the recipient. We are talking about intermediaries because these services receive mail, can sometimes change it, and then send it to one or more other entities. This is the indirect mail flow.

It is here that the ARC system intervenes, since it has the advantage of keeping the results of the authentication of emails when they pass through several intermediaries, allowing the receiver of the message to decide to receive the mail in question after having consulted the results of the ARC. This protocol therefore gives much more chances to the legitimate messages to be distributed correctly, even after passing through several intermediaries. It also provides courier services reliable and secure to manage email authentication, including messages through multiple senders.