How does ARC preserve authentication results through forwarding?

When you forward an email, SPF almost always fails. The forwarding server isn't listed in your SPF record. DKIM can also break if the message body or headers get modified along the way. So how does a downstream mailbox provider know the message was legitimate before all of that happened?

That's what Authenticated Received Chain (ARC) solves. ARC is a set of three headers added by each intermediary (forwarder, mailing list server, etc.) that receives and passes on the message. Each hop stamps the authentication results it observed at that point and signs them cryptographically.

Think of it like a chain of custody. The first server says: "When I received this, SPF passed and DKIM passed. I'm signing that fact." The next server sees the signed record and adds its own. The final destination can look back through the chain and see the original authentication state, even if the current state is broken.

ARC doesn't override DMARC policy. If your domain has p=reject and a forwarder sends on your behalf, ARC lets the receiving server make an informed judgment call. Many major mailbox providers will honor ARC vouching from trusted intermediaries and deliver the message anyway rather than hard-rejecting it.

ARC uses three headers: ARC-Authentication-Results (the auth snapshot), ARC-Message-Signature (similar to DKIM, signs the message content), and ARC-Seal (seals the whole ARC set to prevent tampering). Each hop adds one instance of each, so you can trace the full path.

You can inspect ARC headers in any email's raw source. If you're seeing forwarding-related auth failures, the ARC-Seal header tells you how many hops the message took. Our free Review My Emails Email Header Analyzer parses them for you if reading raw headers feels like decoding ship manifests.