ARC Email Authentication: What it is and How it Works

Email authentication helps prove that an email really comes from the sender it claims to be from. Protocols like SPF, DKIM, and DMARC work together to protect organizations and recipients from phishing, spoofing, and other email-based attacks. However, ARC email authentication was introduced to solve a problem these protocols cannot always handle on their own.

These authentication protocols work well when an email travels directly from the sender to the recipient. However, many legitimate emails don’t follow a direct path. They may pass through mailing lists, email forwarding services, secure email gateways, or other intermediary systems before reaching the recipient.

The problem is that these intermediary services sometimes make small changes to the email, such as adding a footer, scanning attachments, or forwarding it from a different server. Even though these changes are harmless, they can cause SPF, DKIM, or DMARC checks to fail because those protocols expect the email to remain mostly unchanged during transit.

As a result, a legitimate email can look suspicious to the receiving mail server. It may be marked as spam or even rejected, despite coming from a trusted sender. ARC preserves the authentication results from each step of the email’s journey, giving receiving mail servers the context they need to identify legitimate forwarded emails more accurately.

What is ARC Email Authentication

ARC stands for Authenticated Received Chain. It is an email authentication standard that records the authentication results of an email as it moves through different mail servers. Instead of checking only the final version of a message, receiving servers can also review how the email was authenticated at earlier stages.

Unlike SPF, DKIM, or DMARC, ARC does not verify the sender’s identity or publish a policy. Instead, it shares trusted authentication results between participating mail servers. This gives recipients more information to evaluate email ARC, especially when a legitimate message has been forwarded or modified by an intermediary.

How Does Email Authentication Work

The following steps explain how ARC email authentication works as an email travels from the sender to the recipient.

The First Mail Server Authenticates the Email

The first mail server that receives the email checks whether it passes SPF, DKIM, and DMARC authentication. These checks help confirm that the email comes from the claimed sender and has not been tampered with. If the email passes these checks, the server records the authentication results instead of discarding them. These records become the starting point of the ARC chain.

Each Intermediary Preserves the Authentication Results

If the email is forwarded through a mailing list, security gateway, or another mail server, that server performs its own checks as well. Instead of replacing the previous authentication results, it adds a new ARC record while keeping the older ones. This creates a complete history of how the email was authenticated at each stage of its journey.

The Final Receiving Server Evaluates the Chain

When the email finally reaches the recipient’s mail server, it reviews the entire ARC chain along with the latest SPF, DKIM, and DMARC results. This gives the server a better understanding of what happened to the email during transit. Even if forwarding caused some authentication checks to fail, the earlier ARC records can show that the message was originally legitimate, helping the receiving server make a more informed decision.

The Three ARC Headers Explained

ARC email authentication uses three special email headers to keep track of an email’s authentication as it moves from one mail server to another. Each header has a different job, and together they help receiving servers understand whether a forwarded email can still be trusted.

ARC-Authentication-Results (AAR)

The ARC-Authentication-Results (AAR) header stores the results of the authentication checks performed by a mail server. It records whether the email passed or failed SPF, DKIM, and DMARC. Every server that receives the email adds its own AAR header, creating a record of the authentication results at each stage of the email’s journey.

ARC-Message-Signature (AMS)

The ARC-Message-Signature (AMS) header adds a digital signature to the email. This signature helps show that the email looked the same when that mail server processed it. If someone changes the message after that, the signature will no longer match, making it easier for the next server to spot unexpected changes.

ARC-Seal (AS)

The email ARC seal protects the ARC information added by a mail server. It signs the AAR and AMS headers so they cannot be changed without being detected. Every trusted server adds its own email ARC seal, creating a chain that shows how the email moved through different servers. The final receiving server checks every seal in the chain before deciding whether to trust the forwarded email.

Example of an ARC Authentication Flow

The following example shows how ARC headers are added as an email moves through different mail servers.

Sender

↓ 

Microsoft 365

↓

Mailing List

↓

Google Workspace

↓

Recipient  

First, the sender sends an email. When Microsoft 365 receives it, it checks SPF, DKIM, and DMARC. It then adds its own AAR, AMS, and ARC-Seal headers before sending the email to the next server.

Next, the email reaches a mailing list. The mailing list may add a footer or make other small changes before forwarding it. It also performs its own checks and adds another set of ARC headers while keeping the earlier ones.

Finally, Google Workspace receives the email. Instead of looking only at the latest authentication results, it reviews the complete ARC history created by the previous servers. This helps it understand that the email started as a legitimate message, even if forwarding changed some parts of it along the way.

When Should Organizations Use ARC

Here are some situations where enabling ARC can be especially useful. 

Microsoft 365

Organizations using Microsoft 365 often have emails that pass through security tools, forwarding rules, or shared mailboxes before reaching recipients. ARC helps maintain trust in these messages, making it easier for other mail providers to recognize them as legitimate.

Google Workspace

Google Workspace users can benefit from ARC when emails are routed through third-party services before delivery. It gives receiving mail servers extra information about the email’s authentication history, helping reduce the chances of valid messages being treated as suspicious.

Mailing List Providers

Mailing list providers often add footers, subject line tags, or unsubscribe links to outgoing emails. Since these changes can affect authentication checks, ARC helps preserve the original authentication results so recipients can better evaluate the message.

Email Gateways

Many organizations use email gateways to filter spam, scan attachments, enforce security policies, or apply compliance rules. Because these gateways process emails before delivery, ARC helps preserve authentication information across each stage of email handling.

Universities

Universities manage large volumes of emails between students, faculty, researchers, and external organizations. Since these messages are often forwarded between different departments and systems, ARC helps reduce delivery issues for legitimate academic and administrative communications.

Large Enterprises

Large enterprises usually have complex email environments with multiple business units, cloud services, and security platforms. ARC helps maintain authentication information as emails move across these systems, making email delivery more reliable without changing existing authentication protocols.

Customer Support Platforms

Customer support platforms often send replies, ticket updates, and notifications on behalf of an organization’s domain. ARC helps receiving mail servers better understand these emails when they pass through the support platform, reducing the risk of legitimate customer communications being blocked.

How to Enable ARC

The steps to set it up may be slightly different depending on your email provider, but the basic process is almost the same:

• First, check if your email service, mail server, or security gateway supports ARC. If it does, turn on ARC signing in the settings. This allows your server to add the required ARC headers, including the email ARC seal, to forwarded emails.

• Next, send a few test emails and check whether the AAR, AMS, and email ARC seal headers are being added correctly. You should also test forwarded emails to ensure the ARC chain remains complete. 

• Finally, analyze DMARC aggregate (RUA) reports to confirm that ARC is working properly and to fix any issues that appear.

EasyDMARC for Better Authentication, Deliverability, and Visibility

ARC works best when your SPF, DKIM, and DMARC records are set up correctly. EasyDMARC helps you configure and manage these authentication protocols, giving you a strong foundation before enabling ARC.

Once ARC is in place, the EasyDMARC DMARC Report Analyzer helps you understand your DMARC reports in an easy-to-read format. It can help you spot authentication problems, including issues caused by forwarded emails, so you can fix them before they affect email delivery.

Want to improve your email authentication? Start your EasyDMARC 14-day free trial and see how easy it is to monitor, manage, and strengthen your email security.

Frequently Asked Questions