Why Legitimate Forwarded Emails Can Fail SPF

Automatic forwarding can preserve the original envelope domain while sending from the forwarder's IP, causing SPF to fail. That can be an expected result rather than a fault in the sender's policy. Surviving aligned DKIM can pass DMARC; SRS changes the envelope identity, and ARC can inform a receiver's decision. Adding every forwarder to SPF is not the fix.

Automatic forwarding makes a new delivery connection. SPF checks that new connection, so the result at the final mailbox can differ from the result at the first receiver.

This concerns forwarding rules and relay services. Clicking Forward to send a new message from your own mailbox is a different sending arrangement.

The second receiver sees another connection

Consider a message with the envelope domain example.com. Its authorised sender delivers it to a forwarding service, where SPF passes.

If the forwarder preserves that envelope domain, the final receiver checks the forwarder's IP against example.com's policy. The forwarder may not be authorised there, so SPF can fail even though the original sending connection passed.

That failure can be expected for the route. It does not prove the original message was forged, and it does not by itself identify a DNS mistake to repair.

Some forwarding services rewrite the envelope sender, changing the identity evaluated by SPF. The message headers and receiver's results show which arrangement occurred.

DKIM can survive the journey

An aligned DKIM signature can remain valid through forwarding and supply the DMARC pass when SPF fails. Relevant changes to signed headers or the body can invalidate it. Google's forwarding guidance explains why preserving the signed content matters.

A forwarded message that loses DKIM may therefore have a different problem from one that preserves it. Changing the original SPF record cannot repair a signature broken by an intermediary.

SRS changes the envelope identity

The Sender Rewriting Scheme, or SRS, replaces the envelope sender with an address associated with the forwarder and supports returning delivery failures to the original sender. It leaves the visible From address unchanged. Microsoft documents its SRS implementation.

SPF can then pass for the forwarding domain. If that domain does not align with the original visible From, the pass does not satisfy DMARC for the original sender. SRS alone therefore does not solve the DMARC problem; a surviving aligned DKIM signature can still supply the qualifying pass.

ARC gives the receiver earlier evidence

Authenticated Received Chain, or ARC, lets intermediaries attach signed authentication assessments. A receiver may use them when current authentication has been affected in transit.

A valid ARC chain is not an instruction to trust every intermediary. RFC 8617 leaves trust decisions to the receiver. Microsoft's trusted ARC sealer configuration is one implementation of that decision.

ARC does not rewrite SPF or repair DKIM. It supplies additional evidence that can affect handling.

The sender cannot fix every recipient's forwarder

Recipients choose forwarding services outside the original sender's control. Adding arbitrary forwarders to the sender's SPF policy broadens authorisation and may be irrelevant to the domain actually being checked.

For a delivery problem, the useful evidence is the failure response or final receiver's authentication results. The forwarder or receiving administrator may need to act. A known SPF failure on a successfully delivered, DKIM-aligned forwarded message does not inherently need intervention.

Our authentication explanation covers the identities involved. Forwarding is a reason to understand those identities, not a reason to keep expanding the original sender's SPF record.