arc=pass

arc=pass means the message arrived with an Authenticated Received Chain (ARC) and every link in it checked out. Each intermediary that handled the message, such as a mailing list, a forwarding service or a security gateway, recorded the authentication results it saw and sealed them with a signature. The receiver verified all of those seals. What that buys you depends entirely on whether you trust the intermediaries.

What the RFC says

RFC 8617 §4.4 defines three chain validation statuses. Pass means a chain was present and validated. The validator's steps are in §5.2: the chain must have no gaps in its instance numbers, the newest ARC-Message-Signature must verify, and every ARC-Seal must verify, from newest to oldest. §6 says the result is reported in Authentication-Results under the arc method. ARC is an Experimental RFC, and support varies between mailbox providers.

arc= versus cv=

Two different fields carry similar words:

• arc= in Authentication-Results is the receiving server's verdict on the whole chain when it arrived.
• cv= in each ARC-Seal (§4.1.3) is what that sealer found when the message reached it. The first seal, i=1, always says cv=none, because there was no chain before it. Later seals say cv=pass (§5.2).

Authentication-Results: mx.example.org;
       dkim=fail (body hash did not verify) header.d=example.com;
       dmarc=fail header.from=example.com;
       arc=pass (i=1 spf=pass dkim=pass dmarc=pass fromdomain=example.com)
ARC-Seal: i=1; a=rsa-sha256; d=lists.example.net; s=arc1; cv=none; b=...
ARC-Authentication-Results: i=1; lists.example.net;
       spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

This is the classic case. The list lists.example.net received a properly authenticated message, added its footer (breaking DKIM), and sealed what it had seen. On arrival DMARC failed, but the ARC chain shows it passed upstream. §7.2.1 allows a receiver to accept the message on that evidence as local policy, usually only for sealers it trusts.

If you received this message

Read the ARC-Authentication-Results with i=1. It shows what the first intermediary saw, which is the closest you will get to the original authentication. Then check who sealed it: the d= in the ARC-Seal. A valid seal from an unknown domain proves nothing beyond "this domain vouches for its own records". Anyone can add ARC headers (§5.1.4). The analyser explains each ARC header it finds.

If you run a list or forwarder

Keep sealing, and make every change to the message before you seal. If a seal stops verifying, you will see arc=fail downstream. If you are a domain owner reading your DMARC reports, ARC-based overrides may show up there as a local policy reason, which explains why some failing mail was still delivered.