What is ARC?

Authenticated Received Chain (ARC) a standard that can successfully mitigate issues of failure in DMARC authentication. Activate DMARC ARC!

by

Reading Time: 5 min
What is ARC?
Table Of Contents−

What is ARC (Authenticated Received Chain)?

ARC Email 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 sequence of verification 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, Email ARC enables the receiving server to validate emails even when SPF and DKIM are rendered invalid by an intermediate server.

DMARC ARC

DMARC ARC is an effective way to bypass vulnerabilities that may exist in your DMARC authentication system as a result of email forwarding. It preserves email information in a way that helps these messages pass authentication checks. While you require your unauthorized emails to be blocked out, your legitimate emails failing delivery is the last thing that you would want. DMARC ARC maintains a sequence of verification for your emails at every step to ensure that your email headers remain unaltered and are passed on to the next intermediary in the line.

Can ARC be used as a substitute for DMARC?

The answer is no. ARC email was built to pass on authentication identifiers sequentially throughout an email’s journey, no matter how many intermediary servers it goes through. Email ARC helps preserve DMARC verification results, preventing third parties and mailbox providers from modifying message headers or content. ARC is definitely not a replacement for DMARC, rather, it can be used in addition to an enforced DMARC policy to further improve your email deliverability. 

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.

 

ARC

 

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

How Does DMARC 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 Email 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 email 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

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

ARC

  • 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.

ARC

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 DMARC 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 email 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!

ARC

Latest posts by Maitham Al Lawati (see all)
Reasons to avoid SPF Flatteningspf flattening illustrationdns lookups too manyHow to Fix Too Many DNS Lookups?