What is ARC?
ARC (Authenticated Received Chain) is an email authentication standard defined in RFC 8617. It provides a way for intermediate mail servers — such as mailing list managers, email forwarders, and security gateways — to preserve the authentication results they observed when they received a message, so that the final receiving server can evaluate those results even after the message has been modified in transit.
ARC does not replace DMARC, SPF, or DKIM. Instead, it provides a chain of custody that allows receiving servers to make informed decisions about forwarded email that would otherwise fail DMARC.
The Forwarding Problem
When an email is forwarded, two common authentication failures occur:
- SPF breaks:The forwarding server sends the email from its own IP address, which is not listed in the original sender's SPF record. The MAIL FROM domain still points to the original sender, so the SPF check fails.
- DKIM may break: If the forwarding server modifies the email body or certain headers (e.g., adding a footer), the DKIM signature over the body hash becomes invalid.
When both SPF and DKIM fail, DMARC also fails — and the message may be quarantined or rejected, even though it was legitimately forwarded from an authentic original source.
How ARC Works
ARC allows intermediary servers to sign a snapshot of the authentication state at the point they handled the message. Each participating server in the chain adds three new headers to the message:
- ARC-Authentication-Results (AAR): Records the authentication results (SPF, DKIM, DMARC) that the intermediary observed when it received the message.
- ARC-Message-Signature (AMS): A DKIM-like signature over the message content at this point in the chain, including the AAR header. This detects any modifications made after this hop.
- ARC-Seal (AS): A signature over all previous ARC sets plus the new AAR and AMS headers. This seals the entire chain and prevents tampering with earlier ARC records.
Each set of these three headers is numbered with an i= instance tag, starting at 1. Each subsequent intermediary increments the instance number and adds its own set.
ARC Chain Validation
The final receiving server verifies the most recent ARC-Seal, walks back through all ARC-Seal signatures to confirm each is valid, then checks whether the first hop's AAR shows a legitimate original authentication result. If the chain is intact, the server can use this to override a DMARC failure. The decision to trust an ARC chain is the receiving server's policy — ARC provides the evidence; it does not mandate acceptance.
Who Validates ARC?
ARC validation is currently supported by major providers:
- Gmail / Google Workspace: Actively validates ARC chains and uses them to rescue forwarded legitimate mail from DMARC failures.
- Microsoft Exchange Online / Outlook.com: Validates ARC chains as part of Exchange Online Protection.
- FastMail: Supports ARC validation.
ARC signing is commonly performed by mailing list software (e.g., Mailman 3, Sympa), email security gateways, and cloud email platforms that relay mail.
ARC Limitations
ARC is not a trust-all mechanism. The receiving server must decide whether to trust specific ARC sealers based on their reputation. A malicious server could technically forge an ARC chain — but because each sealer signs with its own private key, and the receiving server only trusts known trusted sealers, this attack surface is limited in practice.
ARC also does not help if the original message was never authenticated — it can only preserve and vouch for authentication that already occurred.
Frequently Asked Questions
Do I need to configure ARC for my domain?
If you only send email and do not operate an intermediary (forwarder, mailing list, or security gateway), you do not need to implement ARC signing. ARC is primarily implemented by intermediary mail systems. However, ensuring your outbound emails have valid DKIM signatures means ARC chains initiated by forwarders can reference your original authentication.
Does ARC replace DMARC?
No. ARC is a supplementary mechanism for handling forwarded email edge cases. DMARC remains the primary policy enforcement mechanism. ARC allows receiving servers to make exceptions for messages that fail DMARC due to forwarding — it does not change or weaken DMARC policy for direct email delivery.
Why do some forwarded emails still fail even with ARC?
ARC validation depends on the receiving server recognizing and trusting the ARC sealer. If the intermediary does not sign with ARC, or if the receiving server does not validate ARC for that sealer, the protection does not apply. Additionally, if the ARC chain is broken (any signature invalid), the chain is discarded entirely.