ARC lets an intermediary record the authentication results it saw before it modified a message, and seal that record so a later receiver can check who said it. It is a chain of attestations, not a repair.
What it adds
ARC-Authentication-Results: i=1; mx.list.example; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com ARC-Message-Signature: i=1; a=rsa-sha256; d=list.example; s=arc; ... ARC-Seal: i=1; a=rsa-sha256; d=list.example; s=arc; cv=none; ...
- ARC-Authentication-Results — what this hop saw.
- ARC-Message-Signature — a DKIM-like signature over the message as this hop received it.
- ARC-Seal — a signature over the chain so far, so hops cannot be removed or reordered.
i= numbers the hops, and each new intermediary adds a complete set. RFC 8617 defines it.
What it changes for you
Nothing you control. ARC is added by intermediaries and evaluated by receivers. As the originating domain you neither produce it nor consume it, and there is no ARC configuration on your side.
What it changes is the odds on mail that passes through a modifying intermediary. A receiver that trusts the sealing intermediary may honour the original DMARC result rather than the broken one — and may equally decide it does not trust that intermediary, in which case the chain counts for nothing.
What it does not do
- It does not repair the DKIM signature. The original is still broken; ARC is testimony about what it was.
- It does not entitle anyone to delivery. Honouring a chain is a receiver-side decision based on the intermediary’s reputation.
- It is not something you can publish to fix your forwarding residual. If a lesson or a vendor suggests enabling ARC on your domain to improve DMARC pass rates, it is describing something that does not exist for an originating domain.
- It does not appear in your aggregate reports as a separate outcome. A receiver that overrode a failure on ARC grounds records it in the policy-override field, which is the only place you will see it.
Where you would produce ARC
If you operate something that receives mail, modifies it and sends it on — a mailing list, a ticketing system that relays, a security gateway in front of another organisation — then you are an intermediary and sealing is yours to implement. That is the only circumstance in which ARC is your problem.