Definition
Authenticated Received Chain (ARC), defined in RFC 8617, is an email authentication protocol that preserves the results of SPF, DKIM, and DMARC verification across intermediate servers such as mailing lists and forwarders. Without ARC, forwarded email often fails DMARC because the forwarding server changes the envelope sender (breaking SPF) and modifies the message body or headers (breaking DKIM). ARC seals the authentication results at each hop so that the final recipient can trust the original authentication verdict.
ARC works by adding three sets of headers to the email as it passes through each intermediate server. The ARC-Authentication-Results header records the authentication results from the previous hop. The ARC-Message-Signature header signs the message and all previous ARC headers to chain them together. The ARC-Seal header signs the entire set of ARC headers for the current hop, creating a tamper-evident chain. Each intermediate server adds its own set, creating a verifiable chain from the original sender to the final recipient.
Adoption of ARC varies across mailbox providers. Gmail validates ARC and uses it to inform delivery decisions, particularly for forwarded mail. Yahoo also validates ARC. Outlook has partial support; older Outlook.com infrastructure may not fully honour ARC-sealed authentication results. The result is that some forwarded mail that would pass DMARC at Gmail still fails at Outlook, making ARC an important but incomplete solution for the forwarding problem.
Best Practices
Implement ARC on any server that forwards or modifies email, including mailing list managers, email forwarding services, and email gateways. Without ARC, forwarded mail from these systems is likely to fail DMARC at receiving ISPs.
Verify that your mailing list software supports ARC signing. Major platforms such as Mailman 3, Google Groups, and forwarding services like Fastmail support ARC, but older or custom-built list managers may not.
Monitor ARC validation results using Authentication-Results headers. If you see arc=pass for forwarded mail, the chain is intact. An arc=fail result indicates a broken chain, often caused by message modification after ARC signing.
Do not rely on ARC alone. SPF, DKIM, and DMARC remain the primary authentication layer. ARC is a supplementary mechanism that preserves those results through forwarding.
Test ARC configuration by sending emails through your forwarding infrastructure to Gmail and Yahoo, then inspecting the ARC headers in the delivered message. Confirm that each hop adds a valid ARC set and that the final ARC seal validates.
Consider DMARC quarantine or reject policies carefully when your audience includes subscribers who use email forwarding services. Strict DMARC policies without ARC support from all major providers can result in deliverability failures for legitimate forwarded mail.
Frequently Asked Questions
SPF and DKIM break when an email is forwarded. The forwarding server changes the envelope return path (breaking SPF) and may alter headers or content (breaking DKIM). DMARC then fails because it requires at least one of SPF or DKIM to pass with domain alignment. ARC preserves the pre-forwarding authentication results so the final recipient can still determine trustworthiness.
No. ARC preserves DMARC results across hops but does not replace the need for DMARC policies. Senders should still publish DMARC records and receivers still evaluate DMARC. ARC is an additional layer that helps forwarded mail survive DMARC enforcement.
Microsoft Outlook and Outlook.com have lagged in ARC adoption. While some infrastructure validates ARC, the legacy Outlook.com platform does not consistently honour ARC seals. This means forwarded mail to Outlook addresses may fail DMARC even if it passes at Gmail. Microsoft has indicated ongoing development of ARC support.
ARC is designed to be tamper-evident. Each ARC set is cryptographically signed by the intermediate server. If any ARC header is modified after signing, the seal validation fails. However, ARC relies on the trustworthiness of the intermediate servers; if a forwarding server is compromised, it could sign false authentication results.
Direct sending does not require ARC because SPF, DKIM, and DMARC work without intermediate hops. ARC is only necessary when your email passes through forwarding or mailing list servers before reaching the final recipient.