The one-sentence version#
ARC preserves authentication results across intermediaries such as mailing lists and forwarders. Each hop signs the results it saw, so the final receiver can trust an earlier pass even if SPF or DKIM broke in transit.
Why you should care#
Forwarding and mailing lists are the largest source of legitimate DMARC failures. ARC lets receivers accept mail that would otherwise be quarantined under p=reject.
The mental model#
Think of ARC (Authenticated Received Chain) as a contract between you and the mailbox providers receiving your mail. You publish or configure something they can check; they check it on every message; the result feeds their decision about where your message lands. Everything below is about making that check pass consistently.
Your first setup, step by step#
- Check whether your inbound gateway or mailing-list software supports ARC sealing.
- Enable ARC sealing on any system that modifies and re-sends mail.
- Verify ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results headers appear on forwarded mail.
- Confirm downstream receivers (Gmail, Microsoft) honor your seals by checking Authentication-Results for arc=pass.
Words you will see#
- Mailbox provider: Gmail, Microsoft, Yahoo, Apple, and the corporate gateways that decide where mail lands.
- Authentication: proof that a message is from who it says it is (SPF, DKIM, DMARC).
- Reputation: the provider's running score of your domain and IP.
- Placement: whether a message reaches the inbox, spam, or is rejected.
Common mistakes#
- Expecting ARC to fix your own outbound authentication; it only helps intermediaries.
- Trusting ARC from unknown sealers, which reopens the spoofing door.
Frequently asked questions#
Do I need ARC as a sender?
No. ARC is implemented by intermediaries and receivers. Senders benefit indirectly when their mail is forwarded.
Which providers honor ARC?
Gmail, Microsoft, and Yahoo all evaluate ARC when deciding whether to override a DMARC failure.