Why you shouldn't jump on the SPF bandwagon


SPF is a very broken anti-forgery technique which you should not implement. You should neither publish SPF records, nor check SPF on incoming email.

If you use SPF to reject mail, you will be causing genuine email to be rejected. There are much better alternatives which address the forgery problem without throwing the baby out with the bathwater.

OK, so what is SPF?

SPF is Sender Policy Framework, formerly known as Sender Permitted From. It makes the assumption that mail from a given email address will only ever be seen when sent directly from certain IP addresses which are associated with that address, and it gives the domain owner a way to specify which IP addresses are 'acceptable'.

So, for example, I might state that mail from the infradead.org domain will only be seen from hosts with hostnames ending in 'infradead.org', from the IPv4 subnets or, or from the IPv6 subnet 2001:b80:10b::/48. The idea would be that if you ever see a mail claiming to be from an address at infradead.org which is coming from a different host, then you should know that it's a forgery.

(That's about as far as the pretty graphical but mostly content-free official explanation goes, but if you take a moment to look closer or think about it, there's a little bit more to it than that...)

Unfortunately, this assumption is false. You do see perfectly genuine mail from my domain, from machines other than mine. This happens due to mail forwarding. People tend to change their ISP quite often, but don't want to have to tell everyone that they've changed their email address. So they have an account elsewhere, at a vanity domain or on another computer, and they forward mail from that address to whichever is their current ISP, or their employer.


There is a proposed solution to this -- the SPF advocates say that the whole world should 'upgrade' to make the initial flawed assumptions on which SPF is based come true.

Their idea is that when a server forwards a mail, it shouldn't just use the original sender's address as has been done for the last couple of decades. Instead, it should munge the sender's address as it resends the mail, faking an address at the domain which is actually responsible for the forwarding. Then, if a bounce is generated, that faked address receives the bounce and the bounce needs to be forwarded on to the original sender of the original mail.

This forwarding of bounces could be easily abused if done naïvely, so the idea is that we also include a timestamp to time-limit it, and a cryptographic hash which can only be generated locally. And of course you have to include the original sender's address; both the domain and the username. So when Bill Gates sends me an email to my vanity domain, for example, and my computers forward it to my current ISP, they'd actually end up rewriting the sender address to: SRS0=hh=tt=microsoft.com=bgates@infradead.org instead of leaving it intact.

This rewriting scheme they call 'SRS', and they need it to be implemented everywhere before they can use SPF without throwing away genuine mail.

Problems with SPF

You may have managed to spot one or two potential problems with this scheme all by yourself, but some people do seem to have trouble so let's spell them out explicitly:


In summary, SPF doesn't really achieve what it sets out to achieve, and it breaks far more than it's worth. The costs far outweigh the benefits.

Some SPF advocates would claim that you can't make an omelette without breaking eggs; that the spam problem has got so bad that we have to break things and switch to a new email system.

That's silly for two reasons. Firstly, if you're going to break the world and make people upgrade, you might as well just switch wholesale to something like Internet Mail 2000 rather than pretending it's still compatible with SMTP. SMTP has enough other problems (like the way bounces are done, the difficulty of implementing variable preferences for different users, etc.) that we might as well fix it all at once, if we find it necessary to make such an incompatible change.

Secondly, and more relevantly, there are alternative schemes which give a measure of protection against address forgery but without the flawed assumptions, the loss of genuine mail, and the need for the rest of the world to 'upgrade'. You would have to be mad to choose all the problems of SPF, when other schemes are far saner can and offer the same benefits:

Further reading

"When banks start DomainKeys or S/MIME signing all outbound mail, I promise to give up SPF and Sender ID."
-- Meng Weng Wong, inventor of SPF.

David Woodhouse
Last modified: Thu Jan 13 14:09:11 GMT 2005