Why forwarding breaks SPF and what to inspect next

Define the decision

Forwarding changes the server that connects to the final receiver. The original domain may not authorize that forwarding server. Adding an arbitrary forwarder to the original policy is usually the wrong first response.

Work through the procedure

1. Compare a direct receipt with a forwarded copy.
2. Record the connecting server and envelope domain at the final hop.
3. Check whether an aligned DKIM signature survived the route.
4. Ask the forwarding administrator about supported forwarding and authentication handling.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Direct path: original server → recipient, SPF passes
Forwarded path: original server → forwarder → recipient, original envelope retained
Final SPF evaluates the forwarder against the original domain
Next check: surviving aligned DKIM and trusted forwarding evidence

Read the result

The contrast identifies an indirect-path issue. It does not establish that the original sender should authorize every forwarding service or that all forwarded messages must fail DMARC.

Check before moving on

1. Keep both original messages for comparison.
2. Check for body modifications that also affect DKIM.

Limits and next action

Fixes belong to the relevant sending or forwarding administrator. Do not disable domain policy globally to accommodate one unexplained forwarding route.

Source: RFC 7208: SPF and forwarding considerations