Your Comprehensive Guide to Authenticated Received Chain (ARC) System for DMARC

ARC or Authenticated Received Chain is an email authentication system that displays an email’s authentication assessment each step of the way, throughout handling. In simpler terms, the Authenticated Received chain can be termed as a “ chain of custody” for email messages that enable each entity that handles the messages to effectively see all the entities that previously handled it. As a relatively new protocol published and documented as “Experimental” in RFC 8617 on July 2019, ARC enables the receiving server to validate emails even when SPF and DKIM are rendered invalid by an intermediate server.

How Can Authenticated Received Chain Help?

As we already know, DMARC allows an email to be authenticated against the SPF and DKIM email authentication standards, specifying to the receiver how to handle the emails that fail or pass authentication. However, if you implement DMARC enforcement at your organization to a strict DMARC policy, there are chances that even legitimate emails such as those sent through a mailing list or a forwarder, may fail authentication and not get delivered to the receiver! Authenticated Received Chain helps mitigate this problem effectively. Let’s learn how in the following section:

Situations in Which ARC Can Help

• Mailing Lists 

As a member of a mailing list, you have the power to send messages to all members in the list at one go by addressing the mailing list itself. The receiving address then subsequently forwards your message to all list members. In the current situation, DMARC fails to validate these types of messages and the authentication fails even though the email has been sent from a legitimate source! This is because SPF breaks when a message is forwarded. As the mailing list often goes on to incorporate extra information in the email body, the DKIM signature can also be invalidated due to changes in the email content.

• Forwarding Messages 

When there is an indirect mail flow, such as you are receiving an email from an intermediate server and not directly from the sending server as in the case of forwarded messages, SPF breaks and your email will automatically fail DMARC authentication. Some forwarders also alter the email content which is why the DKIM signatures also get invalidated.

 

 

In such situations, Authenticated Received Chain comes to the rescue! How? Let’s find out:

How Does ARC Function?

In the situations listed above, the forwarders had initially received emails that had been validated against DMARC setup, from an authorized source. Authenticated Received Chain is developed as a specification that allows the Authentication-Results header to be passed on to the next ‘hop’ in the line of the message delivery.

In case of a forwarded message, when the receiver’s email server receives a message that had failed DMARC authentication, it tries to validate the email for a second time, against the provided Authenticated Received Chain for the email by extracting the ARC Authentication-Results of the initial hop, to check whether it was validated to be legitimate before the intermediary server forwarded it to the receiving server.

On the basis of the information extracted, the receiver decides whether to allow the ARC results to override the DMARC policy, thereby passing the email as authentic and valid and allowing it to be delivered normally into the receiver’s inbox.

With ARC implementation, the receiver can effectively authenticate the email with the help of the following information:

• The authentication results as witnessed by the intermediate server, along with the entire history of SPF and DKIM validation results in the initial hop.
• Necessary information to authenticate the sent data.
• Information to link the sent signature to the intermediary server so that the email gets validated in the receiving server even if the intermediary alters the content, as long as they forward a new and valid DKIM signature.

Implementation of Authenticated Received Chain

ARC defines three new mail headers:

• ARC-Authentication-Results (AAR): First among the mail headers is the AAR that encapsulates the authentication results such as SPF, DKIM, and DMARC.

• ARC-Seal (AS) – AS is a simpler version of a DKIM signature, that contains information on authentication header results, and ARC signature.

• ARC-Message-Signature (AMS) – AMS is also similar to a DKIM signature, which takes an image of the message header which incorporates everything apart from ARC-Seal headers such as the To: and From: fields, subject, and the entire body of the message.

Steps performed by the intermediate server to sign a modification:

Step 1: the server copies the Authentication-Results field into a new AAR field and prefixes it to the message

Step 2: the server formulates the AMS for the message (with the AAR) and prepends it to the message.

Step 3: the server formulates the AS for the previous ARC-Seal headers and adds it to the message.

Finally, to validate the Authenticated Received Chain and find out whether a forwarded message is legitimate or not, the receiver validates the chain or ARC Seal-headers and the newest ARC-Message-Signature. If in case the ARC headers have been altered in any way the email consequently fails DKIM authentication. However, if all mail servers involved in the transmission of the message correctly sign and transmit ARC then the email preserves the DKIM authentication results, and passes DMARC authentication, resulting in the successful delivery of the message in the receiver’s inbox!

ARC implementation backs-up and supports DMARC adoption in organizations to make sure that every legitimate email gets authenticated without a single lapse. Sign up for your free DMARC trial today!