How does ARC help preserve authentication results during forwarding?

Think of Authenticated Received Chain (ARC) like a chain of custody document for your email. Every time a legitimate intermediary passes along your email (a mailing list, an alias, a forwarding service), ARC lets that intermediary record the authentication results they saw and sign their attestation. The final receiving server can look at that chain and decide: do I trust this forwarder?

Without ARC, a legitimately forwarded email and a spoofed one look identical at the end of the chain. Both show broken SPF and possibly broken DKIM. ARC gives receivers a way to distinguish between them.

ARC adds three headers at each hop in the chain:

• ARC-Authentication-Results: The SPF, DKIM, and DMARC results at that specific hop
• ARC-Message-Signature: A DKIM-style signature over the message as received at that hop
• ARC-Seal: A signature that locks in the entire ARC chain so nobody can tamper with earlier entries

This matters most when a mailing list or forwarding service modifies the email (adding footers, changing subject lines) and breaks the original DKIM signature. ARC records what authentication looked like before that modification happened. The receiving server can then honor that historical record rather than rejecting the email outright.

Both the forwarder and the receiving server need to support ARC for it to work. Gmail and Outlook have implemented ARC support on the receiving side, so most forwarding through those providers is covered. Smaller providers may not check ARC chains yet. ARC works in concert with DMARC to give receivers enough context to make an informed decision on forwarded mail.

And If your recipients frequently use mailing lists or forwarding and you're seeing DMARC failures on legitimate mail, check whether your forwarders are ARC-enabled. If things are actively broken, our SOS hotline is free and we can walk through your specific situation.