Sender Policy Framework

Local policy for SPF results must consider forwarders

Forwarding is only a problem for mail recipients who check SPF and do not make provisions for any forwarders they have set up. First of all, realize that the SPF result is deterministic and defined by the SPF specification. You do not get any choice in the matter. However, any decision your mail software makes based on the SPF result is your choice. This advice concerns your "local policy" – how you treat SPF results.

Forwarders are generally set up by the mail recipient – and thus are the responsibility of the mail recipient. Mail senders publishing SPF records should not have to worry about forwarding. (Unless you count greeting card sites that let users enter an arbitrary MAIL FROM and don't follow web generated best practices. This is the sender's choice, in which case they will have to list such greeting card sites they use to send mail – or use "?all".)

Even a large ISP can do it. They might complain that they do not know what forwarders their users have set up. Maybe so, but they can:

1. provide a web-based configuration page to list forwarders.
2. default to not reject messages that fail SPF for users who have not configured their forwarders (but still add the "Received-SPF" header).
3. give users who have configured their forwarders the option of rejecting messages that fail SPF.

If tracking forwarders is simply not possible, then the ISP should not reject emails only because of SPF fail. But they can still use the MAIL FROM domain and SPF result for reputation. For example, the reputation of "example.com:PASS" may be quite different from "example.com:FAIL", and if the reputation of "example.com:FAIL" is bad enough, and ISP may start rejecting - just as they do for IP addresses with bad reputation now.

When configuring a forwarder, all you need to know is whether the forwarder performs sender rewriting, e.g. SRS.

• For non-sender-rewriting forwarders, accept all mail without checking SPF (any SPF results are meaningless). Hopefully, you (or your user) have chosen a forwarder that checks SPF before forwarding. If your implementation allows it, also check SPF for a "pretend" MAIL FROM that your forwarder could use (the original recipient RCPT at the forwarder before the email was forwarded). This verifies that the forwarded mail really came from your trusted forwarder.
• For sender-rewriting forwarders, do check SPF.

For ISPs, it should be obvious that this configuration is per-user. The decision on whether to reject an SPF "fail" is delayed until after the RCPT TO SMTP transaction command, so that per-user configuration can be consulted.

SPF Friendly Options for Forwarders

Forwarders may choose to implement SRS for all senders, only senders with SPF records, or only senders whose messages would fail SPF checks if forwarded. Another option would be to do a prospective SPF check (check if the message would get an SPF Fail if sent from the forwarder's server) and reject the message to be forwarded with 551 User not local; please try <forward-path> (See RFC 821 paragraph 3.2 for details).