The problem it solves

When a mailing list or a forwarding rule passes your message on, the server that finally delivers it sees the forwarder's IP, not yours, so SPF fails. If the forwarder modifies the message — adding a footer, rewriting the subject — DKIM fails too. The message is genuine, it was authenticated when it left you, and now it fails DMARC through no fault of anyone.

At p=reject that message is refused. This is the main reason enforcement is delayed, and ARC is the standards-track answer.

How it works

Each intermediary adds three headers. ARC-Authentication-Results records what SPF, DKIM and DMARC looked like when the message arrived at that hop. ARC-Message-Signature signs the message as it leaves. ARC-Seal signs the whole chain so far. The next hop adds its own set, numbered in sequence. The final receiver can validate every seal back to the first, see that the message passed authentication at the start, and choose to accept it despite the DMARC failure it sees locally.

The receiver still decides. ARC is evidence, not an instruction, and receivers weigh it against how much they trust the sealing domains.

What it means for senders

Almost nothing to do. ARC is implemented by forwarders and receivers; Google Groups, Microsoft 365 and the major mailing-list platforms seal, and Gmail and Outlook.com honour valid chains from trusted sealers. As a sender you see it in the headers of forwarded mail, and you see the effect as a smaller residual DMARC failure rate once you enforce. If your DMARC reports show failures from a source you recognise as a forwarder, that source is either not sealing or not trusted.

Check yours

These run free in your browser. Nothing you type reaches a server.

Common questions