RFC 8617 — ARC

RFC 8617 defines ARC, a way for intermediaries to record the authentication results they saw, so a later receiver can take those into account when the original SPF and DKIM results no longer survive.

It is Experimental, not Standards Track — worth knowing before treating it as something you can rely on.

The problem it addresses

Mailing lists and forwarders routinely break authentication. A list adds a subject prefix or a footer, which invalidates the DKIM signature, and it retransmits from its own servers, which fails SPF. The message is legitimate and DMARC fails anyway. This is the single most common cause of a well-configured domain seeing failures it cannot fix.

What ARC does

Each intermediary adds a sealed set of headers recording what it saw on arrival. A receiver at the end of the chain can validate the chain and decide to trust an earlier pass even though nothing verifies now.

Note the word decide. ARC does not override DMARC; it supplies evidence a receiver may choose to weigh. Whether it does is entirely up to them.

What it means in practice

You do not publish anything for ARC, and there is no ARC record. It is implemented by intermediaries and receivers, not domain owners.

Its practical value to you is in reading reports: if you see DMARC failures from sources that are obviously mailing lists, ARC is the reason some receivers deliver that mail anyway and others do not — and it is why chasing those failures to zero is not a realistic goal.

Why it is Experimental

ARC asks receivers to trust intermediaries, and trust is not something a protocol can confer. A sealed chain proves an intermediary claimed a particular result, not that the claim was honest — so a receiver still has to decide which intermediaries to believe, and that decision is outside the specification.

That is a genuinely hard problem, and it is why the document is Experimental rather than Standards Track. Large mailbox providers do evaluate ARC, but they do so on their own reputation data, and none of them is obliged to.

Reading it in your reports

You will not see ARC directly in an aggregate report — there is no ARC field. What you see is the consequence: DMARC failures from sources that are obviously mailing lists or forwarders, where some receivers deliver the mail anyway and others do not.

If those failures come from real lists carrying real mail, the answer is usually to leave them alone. Driving DMARC failures to zero is not achievable when indirect mail flows exist, and RFC 7960 exists specifically to catalogue why.

Read it: rfc-editor.org/rfc/rfc8617