Sender Policy Framework

Common mistakes when using an SPF record

When your mail server uses someone else's SPF policy, there are a couple of things that could go wrong. Try not to make the same mistakes that others did. Things to look at:

• Process SPF policies at the right place
• Checking SPF On Forwarded Mail
• Guessing is OK, provided that...
• Returning mail to sender
• Tell your users

Processing SPF policies at the border

SPF is designed to work at the border of your network. Some server, which you may not know, is contacting your server. Can you trust it? An SPF policy designates (or not!) that server as an authorized source for email from $domain.

Now consider what happens if you process an SPF policy somewhere else in your network. For example: one host receives all mail and then relays it to a central mail server. Should you process SPF policies on that central mail server, it will see your other host as the source. Chances are this other host is not authorized by someone else's SPF policy!

Example:

user@example.com sends his mail via mailhost.example.com and this host is authorized in example.com's SPF policy (v=spf1 a:mailhost.example.com -all).

Your organization receives mail at mailhost.receiver.example (your MX server). Maybe it looks at example.com's SPF record, finds that mailhost.example.com is authorized, and all is well.

Then the message is relayed to mailcentral.receiver.example; if this server looks at the SPF record again, the sending host will be mailhost.receiver.example which is not authorized!

Another example:

Your organization has a primary MX host, and a backup. Somehow delivery via the primary MX fails. The secondary MX is used and stores mail for a while. After some time, messages are routed to the primary for further processing.

In this example, the secondary MX should look at SPF policies (just like the primary does). Its settings should be at least as secure as the primary's settings. In addition, the primary MX server should whitelist the secondary MX server. All security checks are done by the secondary MX and should not be repeated for the following reasons:

• it is a waste of resources
• (for SPF: ) the sending host is your MX server, not the original contacting server

Checking SPF On Forwarded Mail

Mail forwarding is set up by the receiver and so for forwarded mail, the border mail server (at which SPF should be checked) the the forwarder's mail server. If you check SPF on your mail server it is coming from your forwarder and not from a mail server authorized by the sending domain. Technically this is similar to checking SPF against mail relayed from your secondary MX like discussed in the previous item. Authorized forwarders should be whitelisted against SPF checks to avoid this problem.

Enabling a "best guess" mode

Some SPF programs know how to fake an SPF policy if the sending domain does not have one. This is generally OK but you really should avoid this one big mistake: you must not reject mail based on your own guess, and you must not blame SPF if you ignore this warning!!!

Returning ("bouncing") email

It is generally best to reject mail right at the border of your network, rather than to accept responsibility for it ("receive") and find yourself returning email to a third party. But it becomes even more important when you process SPF policies.

Consider this: you receive a message from <president@whitehouse.gov>. You accept the message (and thus responsibility for it) but you soon find that you cannot deliver it. According to the RFC you ought to return it to the sender.

If whitehouse.gov has an SPF policy, and if that SPF policy did not approve of the sending server, then you can assume that president@whitehouse.gov is not the sender. When you "return" the message to this address, you are part of the problem, not part of the solution.

Tell your users

Don't forget to tell people that you are about to implement SPF. Some senders (inbound mail from your perspective) use unauthorized relays but so far nobody noticed. As soon as you start verifying SPF, people will notice and blame it on the most recent change (i.e. you implementing SPF verification). The real problem is those senders. Make sure your users know this.