Implement ARC (Authenticated Received Chain) to preserve authentication through email forwarders

Verified steps

1. Understand the problem ARC solves: when a message is forwarded (by a mailing list, alias, or redirect service), SPF fails because the forwarder's IP is not in the original sender's SPF record, and DKIM may break if the message body is modified; DMARC then fails even though the message was originally legitimate.
2. On the forwarding mail server, install and configure ARC signing support: Postfix can use the OpenARC milter; Microsoft Exchange and many commercial MTAs include native ARC support. Generate an ARC signing key pair and publish the public key in DNS under a selector at arc-selector._domainkey.yourdomain.com.
3. When the forwarder receives a message, it must: copy the existing Authentication-Results header into a new ARC-Authentication-Results (AAR) header with i=1, create an ARC-Message-Signature (AMS) covering the message and the AAR, and create an ARC-Seal (AS) covering all ARC headers in the chain.
4. Each intermediate forwarder in a chain increments the i= counter; receiving servers validate the full chain by checking every ARC-Seal and then verifying the most recent ARC-Message-Signature.
5. Receiving servers (Gmail, Microsoft 365) use a passing ARC chain as an override signal when DMARC fails; configure your receiving MTA to trust ARC from known legitimate intermediaries.
6. Test the end-to-end chain using a mailing list subscription: inspect the received message headers for ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results headers and verify the Authentication-Results show arc=pass.