ARC, and why forwarded mail fails authentication

A message that authenticates perfectly on the first hop can fail on the second, with nothing wrong at either end. This is not a misconfiguration — it is what happens when mail is relayed, and it is the reason ARC exists.

What breaks

Forwarding breaks SPF. You send to an address that forwards elsewhere. The forwarder relays the message, so the final receiver sees a connection from the forwarder's server. SPF for your domain does not list that server, so SPF fails. Correctly — the forwarder is not you.

Mailing lists break DKIM. A list that prepends a tag to the subject or appends an unsubscribe footer has changed the content the signature covers. The body hash no longer matches and DKIM fails. Also correctly — the message was modified.

Under p=reject, both become rejections of mail that was legitimate when it was sent.

What ARC does

ARC lets an intermediary record what it saw. When a forwarder receives a message that passed authentication, it adds a set of headers stating so, and signs that statement with its own key.

Three headers per hop: a results header recording the authentication outcome, a message signature covering the message as received, and a seal chaining this hop to any previous ones. Each intermediary adds a set, producing a chain that the final receiver can walk back.

The final receiver can then see: this failed SPF because it was forwarded, but a forwarder I trust says it passed before that.

The catch

ARC is advisory. It supplies evidence; it does not oblige anyone to accept it. The receiver decides whether the sealing intermediary is trustworthy, and that decision rests on the intermediary's own reputation.

Which means ARC helps when a large, well-known forwarder seals, and helps much less when the sealer is a small domain nobody has an opinion about. It is not a mechanism you can deploy on your own side to fix forwarding of your mail.

What you can actually do

Make DKIM correct and alignment solid. DKIM survives plain forwarding — the signature travels with the message. Only modification breaks it. If DKIM aligns, forwarded mail still passes DMARC despite SPF failing, which covers the common case entirely.

Do not panic at forwarding in reports. SPF fail with DKIM pass and aligned, from scattered low-count sources, is forwarding working as intended. It is not a reason to delay enforcement.

If you run a list or a forwarder, implement ARC sealing. You are the intermediary in someone else's version of this problem.

Expect lists to rewrite From. Well-run mailing lists replace the From header with their own domain, which sidesteps the whole issue at the cost of the original sender's name in the display. This is the pragmatic answer most lists settled on.

Where this leaves enforcement

Forwarding is not a reason to stay at p=none. It is a reason to get DKIM right first. Once DKIM aligns, the population of mail that fails DMARC purely because of forwarding is small, and most of what remains is mail you would want rejected anyway.