Why Forwarded Email Fails Authentication

SPF checks the IP address of the server that connects to the receiver against the list published by the sender’s domain. When a message is forwarded, the connecting server is the forwarder, not the original sender, so its IP address is not on the sender’s list. The result is spf=fail or softfail even though nothing malicious happened.

There is no tidy fix from the receiver’s side. Some forwarders rewrite the envelope sender to their own domain so that SPF is evaluated against themselves. That makes SPF pass, but for the wrong domain, which means it no longer aligns with the visible From address for DMARC purposes.

DKIM survives forwarding when the forwarder passes the message on untouched, because the signature still matches the signed content. Mailing list software rarely does. It commonly adds a subject tag such as [list-name] and a footer with unsubscribe text. Both change the signed content, so the original signature no longer verifies and you see dkim=fail.

When both SPF and DKIM fail to align, DMARC fails too. If the original sender publishes a strict policy such as p=reject, receivers may refuse the message outright, which is why mailing lists became a notable casualty when large domains tightened their DMARC policies.

ARC, the Authenticated Received Chain, is defined in RFC 8617. It lets each intermediary record the authentication results it saw when the message arrived, and sign that record. A downstream receiver can then see that the message passed SPF and DKIM at the first hop before the forwarder altered it, and can decide to trust the forwarder’s statement.

ARC adds three headers for each participating hop, tied together by an instance number, written as i=1, i=2 and so on:

• ARC-Authentication-Results: what this intermediary found when the message reached it.
• ARC-Message-Signature: a signature over the message as this intermediary handled it.
• ARC-Seal: a signature covering the ARC headers themselves, which protects the chain from tampering.

An ARC chain does not by itself make a message authentic. A receiver has to decide whether it trusts the intermediaries that sealed it. In practice, large providers keep their own lists of ARC signers they believe, and a chain from an unknown forwarder carries little weight. The presence of ARC headers in a header you are reading tells you the message was forwarded, and that someone considered the problem. It is not a guarantee of anything.

Three signs together point to forwarding. The first is the ARC headers just described. The second is a pair of conflicting authentication results, with a failing spf for the connecting server but a pass in an ARC-Authentication-Results line from an earlier hop. The third is a hop from a domain you recognise as a forwarding service, followed by a gap, because forwarders often queue messages and retry.

If you can see all three, the message was fine at origin and the forwarder is the weak point. Delays at a forwarder are usually down to its own queueing and the receiver’s greylisting of an unfamiliar sending IP.

If you control the forwarding, prefer a method that re-sends the message from your own authenticated domain over one that merely relays the original, and make sure your own SPF, DKIM and DMARC are in order so the forwarded copy is credible. If you run a mailing list, use a platform that supports DMARC-aware handling, which typically rewrites the From address to the list’s domain while keeping the original sender in the display name. If you only want to read old mail in a new inbox, importing it from the old account is more reliable than forwarding.

A message from alice@example.org is sent to bob@oldmail.example, and Bob’s account forwards everything to bob@newmail.example. The final receiver sees the connection coming from oldmail.example’s server, not from example.org’s. SPF checks whether that server is allowed to send for example.org, and it is not, so SPF fails even though nothing dishonest happened.

If the message carried a DKIM signature and the forwarder did not alter it, DKIM still passes and DMARC is satisfied. If the forwarder changed the subject line or added a footer, the signature breaks too. ARC exists for exactly this moment: the forwarder records what the authentication results were when it received the message, and seals that record so the next receiver can see it.

Three signs usually give it away.

• Two or more sets of ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results headers, numbered with an instance number.
• An SPF result that fails or softfails for a message that otherwise looks legitimate.
• A Received line showing the message arriving from a server belonging to a different organisation than the sender’s.

Mailing list software often adds a subject tag or a footer, which changes the signed content and breaks the original DKIM signature. Many lists now rewrite the From address or re-sign messages themselves to stay within DMARC, which is why a list post can appear to come from the list and not from the person who wrote it. It is a workaround, and it is the reason header analysis of list mail needs a little extra care.

When you are diagnosing mail that went through a forwarder or a list, read the earliest authentication results you can find. ARC is designed to preserve them, and they tell you what the message looked like before it was modified.