Why Legitimate Forwarded Emails Can Fail SPF

Automatic forwarding changes which server delivers a message. That can cause an SPF failure without anything being wrong with the original sender’s record.

An email can pass SPF on arrival at one mailbox and fail after that mailbox automatically forwards it elsewhere.

The message may be legitimate throughout. The failure happens because the final recipient receives it from the forwarding server, rather than the original sender.

This concerns automatic redirection of an existing message. Clicking Forward and sending a new message is a different case.

The recipient sees the forwarding server

If forwarding preserves the original return address, the final receiver checks the forwarding server’s IP address against the original domain’s SPF record.

That domain may never have authorised the forwarder. SPF can therefore fail even though the original sender used an authorised server. Google’s forwarding guidance

Adding arbitrary forwarding services to the original domain’s SPF would broaden who is authorised to send for it. It is not a general solution to this mismatch.

Forwarding changes the server the recipient checks

View full-size image

Read the diagram as text

1. The original email service is authorised to send for example.com.
2. An automatic forwarding service sends the existing message onward while preserving the example.com return address.
3. The final receiver now checks the forwarding server against example.com's SPF policy.
4. That server may be unauthorised even though the message is genuine. This does not mean arbitrary forwarders should be added to SPF.

DKIM can survive the extra hop

A valid DKIM signature can survive forwarding when the signed parts of the message remain unchanged. If its signing domain aligns with the visible From address, it can let the message pass DMARC despite an SPF failure.

Changes to signed content, such as modifying the subject or body, can break that signature. Whether it survives depends on what was signed and what the forwarding service changes.

One forwarded message, two results

Suppose the original message uses example.com in its From and return addresses. The original server is authorised, but the automatic forwarder is not. If the signed content stays unchanged, the final receiver might record these fictional results:

Authentication-Results: mx.example.net;
  spf=fail smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Here, aligned DKIM lets DMARC pass despite the SPF failure. If DKIM fails too, the same explanation no longer establishes a DMARC pass. Check the forwarding path and any changes to signed content.

Use the email header analyser on a received copy to inspect the results and Received headers. Those fields can support the forwarding explanation; an SPF fail by itself does not prove forwarding caused it.

SRS changes the return address

The Sender Rewriting Scheme, or SRS, lets a forwarder replace the return address with one under its own control. The receiver can then check SPF against the forwarding domain. SRS documentation

That does not also change the visible From address. An SPF pass for the forwarder’s domain therefore does not necessarily provide the alignment DMARC needs.

ARC preserves earlier authentication results

ARC lets intermediaries attach signed records of earlier authentication checks. A receiver that trusts the intermediaries can use that history when assessing a forwarded message. It does not guarantee acceptance. ARC standard and Microsoft’s ARC guidance

SPF flattening addresses a separate issue: too many DNS lookup steps. It does not change the forwarding server’s identity or make it part of the original sender’s authorised infrastructure. A forwarding-related failure needs to be understood in that context.