The Problem ARC Solves
Email forwarding and mailing lists break traditional authentication:
Without ARC
- You send email to a mailing list (DKIM passes, SPF passes)
- Mailing list modifies the message (adds footer, changes subject)
- DKIM signature breaks because content changed
- SPF fails because mailing list server is not in your SPF
- DMARC fails, email goes to spam or is rejected
With ARC
- You send email to a mailing list (DKIM passes, SPF passes)
- Mailing list records original authentication results in ARC headers
- Mailing list modifies message and adds its own DKIM signature
- Final receiver sees ARC chain showing original authentication passed
- Receiver can trust the ARC chain and deliver despite DMARC failure
Chain of Custody
ARC creates a "chain of custody" for authentication. Each intermediary adds a link to the chain, sealing the previous authentication results. The final receiver sees the complete history.
How ARC Works
ARC Headers
ARC adds three headers at each hop:
- ARC-Authentication-Results (AAR): Records SPF, DKIM, DMARC results at this point
- ARC-Message-Signature (AMS): DKIM-like signature of the message at this point
- ARC-Seal (AS): Signature covering the ARC headers, proving chain integrity
Instance Numbers
Each set of ARC headers includes an instance number (i=1, i=2, etc.). This tracks the order of intermediaries the message passed through.
Chain Validation
The receiving server validates the ARC chain by:
- Checking each ARC-Seal signature
- Verifying chain integrity from first to last instance
- Evaluating the original authentication results
- Deciding whether to trust the chain
Common ARC Scenarios
Mailing Lists
Mailing lists often add footers or modify subjects, breaking DKIM. ARC allows the original authentication to be preserved through the list processor.
Email Forwarding
When users forward their email to another account (personal to work), SPF fails because the forwarding server is not authorized. ARC preserves the original SPF result.
Security Gateways
Corporate email security gateways that modify messages can use ARC to preserve original authentication before their modifications.
ARC Support
Who Evaluates ARC
Major receivers that consider ARC in DMARC decisions:
- Gmail (Google)
- Microsoft (Outlook, Office 365)
- Yahoo
These providers may deliver email that failed DMARC if a trusted ARC chain shows original authentication passed.
Who Adds ARC
Intermediaries that commonly add ARC headers:
- Google Groups and other mailing list providers
- Email forwarding services
- Some corporate email security gateways
ARC and DMARC Policy
ARC does not override DMARC. Instead, receivers use ARC to make more informed decisions:
- If DMARC passes, ARC is not needed
- If DMARC fails but ARC shows original auth passed, receiver may still deliver
- Receivers decide whether to trust specific ARC signers
Trusted Sealers
Receivers maintain lists of trusted ARC sealers. They are more likely to honor ARC from known, reputable intermediaries than from unknown ones.
For Senders: What You Need to Know
You Do Not Implement ARC
As a sender, you do not add ARC headers. ARC is added by intermediaries (mailing lists, forwarders) and evaluated by receivers.
Your Responsibility
- Implement proper SPF, DKIM, DMARC
- Understand that some forwarded mail may still fail
- ARC helps but is not a complete solution
DMARC Reports
DMARC aggregate reports show failures that may be legitimate forwarding. High failure rates from certain sources (mailing lists) are expected and not necessarily concerning.