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.
What good looks like#
- Done: Check whether your inbound gateway or mailing-list software supports ARC sealing.
- Done: Enable ARC sealing on any system that modifies and re-sends mail.
- Done: Verify ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results headers appear on forwarded mail.
- Done: Confirm downstream receivers (Gmail, Microsoft) honor your seals by checking Authentication-Results for arc=pass.
What bad looks like#
- Seen in audits: Expecting ARC to fix your own outbound authentication; it only helps intermediaries.
- Seen in audits: Trusting ARC from unknown sealers, which reopens the spoofing door.
How to move from bad to good#
Work through the good list in order and re-verify after each change. Most teams find one or two items from the bad list already present; fixing those usually produces the largest improvement.
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.