A signature valid at the moment of sending can be invalid at delivery, and the message will have been altered by something entirely legitimate. Knowing which intermediaries break signatures tells you whether a failure is an attack or a Tuesday.
What a signature survives
- Plain forwarding. A
.forwardrule or a server-side redirect relays the bytes unchanged. SPF fails, because the relaying host is not authorised. DKIM passes, because nothing was touched. This asymmetry is the single strongest argument for having DKIM at all. - Greylisting, queueing, retries. Delay changes nothing the signature covers, unless
x=expires in the meantime. - Added headers. Received, Authentication-Results and X-* headers are added by every hop and are not in
h=.
What breaks it
| Intermediary | What it does | Which hash fails |
|---|---|---|
| Mailing list | Prepends [list] to Subject, appends a footer | Both |
| Security gateway | Rewrites URLs for click protection | Body |
| Compliance appliance | Appends a disclaimer | Body |
| Anti-virus scanner | Rewrites attachments or adds a scanned-by line to the body | Body |
| Character-set converter | Re-encodes the body to a different charset | Body |
| Subject tagger | Adds [EXTERNAL] to Subject | Signature (header) |
The pattern is worth internalising: a body-hash failure means content was changed; a signature failure with a matching body hash means a signed header was changed. The two point at different culprits.
Why ARC exists
A mailing list that modifies a message destroys a signature it had every reason to trust when it received it. The list knows the message authenticated on arrival; it has no way to say so that a downstream receiver can verify.
ARC is that missing statement. An intermediary records the authentication results it saw and seals that record with its own signature, so a receiver that trusts the intermediary can honour the original result despite the broken DKIM. It does not repair the signature — it provides an attested account of what the signature did before the modification.
ARC is a receiver-side decision
A receiver may act on an ARC chain or ignore it entirely, and whether it does depends on what it thinks of the sealing intermediary. Publishing ARC does not entitle you to delivery; it gives a receiver that already trusts the intermediary grounds to override a DMARC failure it would otherwise honour.
What lists do instead
The practical answer most well-run lists reached is to rewrite the From header to the list’s own domain and sign as themselves. The message then aligns for the list, the original author appears in Reply-To and the display name, and nothing depends on receivers honouring ARC. It is ugly and it works.