ARC Authentication: what it is and why it matters

ARC (Authenticated Received Chain) is an email authentication protocol that records SPF, DKIM, and DMARC results at each hop as a message travels through intermediate servers. The standard is defined in RFC 8617 and is supported by Gmail, Microsoft 365, Yahoo, and other major providers.

The problem ARC solves

SPF, DKIM, and DMARC work well when a message travels directly from sender to recipient. But email is often forwarded: mailing lists, university aliases, corporate relays, auto-forwarding rules. Each intermediary can break the authentication chain.

SPF fails because the forwarding server's IP is not listed in the original sender's SPF record. DKIM may break if the intermediary modifies the message body or headers, say by appending a footer, rewriting the subject, or stripping an attachment. When both SPF and DKIM fail, DMARC fails too, and the message can be rejected or filed as spam even though it started out legitimate.

ARC addresses this by letting each intermediary record what the authentication results looked like before it touched the message. The final receiving server can then examine the ARC chain and decide whether to trust the forwarding path.

How ARC works

When an intermediary server receives and forwards a message, it adds three headers that together form an ARC set:

• ARC-Authentication-Results (AAR) - a snapshot of the SPF, DKIM, and DMARC results as this intermediary saw them when the message arrived.
• ARC-Message-Signature (AMS) - a DKIM-style signature over the message body and selected headers, computed by the intermediary. It captures the content at the moment of forwarding.
• ARC-Seal (AS) - a signature over all prior ARC sets and the current AAR. This links each set to the previous ones, forming the chain.

Each ARC set carries an instance counter (i=1, i=2, and so on). The first intermediary creates set 1, the second creates set 2. The chain is ordered and tamper-evident: changing any earlier set invalidates the seals of every subsequent one.

How the receiving server uses ARC

The final receiving server validates the ARC chain in reverse order, starting from the latest set and working back to i=1. If the chain is intact, the server checks the AAR from set 1 to see what the original authentication results were, before any forwarding occurred.

ARC does not override DMARC; it adds context. A receiving server may reason: "DMARC failed, but the ARC chain is valid, set 1 shows DMARC pass, and I trust this intermediary, so I will deliver." The decision to trust an ARC chain is entirely at the receiver's discretion.

ARC and email deliverability

For an email marketer, ARC is not a setting you configure directly. It lives on the infrastructure side, but your deliverability depends on it. When subscribers forward your messages, say from a work address to a personal one, or through an alias, ARC is what lets the final provider honor the authentication your sending domain originally passed.

Gmail, Microsoft 365, and Yahoo factor in ARC when making delivery decisions. If your domain has correctly configured SPF, DKIM, and DMARC, forwarding servers that support ARC will carry those results along. The destination provider sees that the message passed all checks before forwarding started.

Without ARC, a forwarded message frequently ends up in spam or gets rejected outright. With it, the provider can look past the broken SPF and DKIM and deliver to the inbox.

Limitations

ARC relies on trust in intermediate servers. If a forwarder is compromised or deliberately falsifies ARC headers, the chain looks valid but the data inside it is wrong. Receiving servers need to maintain their own list of trusted intermediaries.

ARC also cannot fix a missing authentication foundation. If the sender has not configured SPF, DKIM, and DMARC, there is nothing for ARC to preserve. The protocol extends existing authentication; it does not replace it.