ARC Chain — Authentication Across Forwarding Hops

Why ARC exists

As soon as an email is forwarded — through a mailing list, a forwarding rule or a gateway — the sending IP changes. SPF validates exactly that IP and therefore fails by necessity. If the forwarder also appends a footer, the DKIM body signature breaks too. The result: a perfectly legitimate message fails DMARC.

The Authenticated Received Chain (ARC, RFC 8617) solves this. Every station that passes a message along seals the authentication result it saw itself. The final recipient can then verify that the message was properly authenticated when first received, even if it no longer is.

What AnalyzeMy.Email checks

• Per hop: the signing domain, the chain validation result (cv=none, cv=pass, cv=fail) and the SPF, DKIM and DMARC results recorded there
• Completeness: every ARC instance needs all three headers — ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal. If one is missing the instance is unusable
• Instance ordering via the i= numbering

Reading the results

• cv=none — this station is the first in the chain. Correct for the first forwarder.
• cv=pass — the preceding chain was validated and is intact.
• cv=fail — the chain is broken. From this point the statements are no longer trustworthy.
• No ARC headers — entirely normal for directly delivered mail and not an error.

Putting it in context

You do not configure ARC on your sending domain — it is a feature of forwarding systems. The check becomes relevant when you analyze a forwarded message and want to understand why SPF fails despite a correct configuration. An SPF fail alongside an intact ARC chain is not a problem with your domain.

If you operate a mailing list or gateway yourself, you should enable ARC sealing. Google and Microsoft evaluate ARC chains and deliver forwarded messages far more reliably because of them.