So, everyone should configure their mail server with SPF immediately!
I've been thinking over this for a while, and I'm still undecided. While some of the practical reasons SPF might be a pain in the ass for some people don't apply to me (most of my mail is run through servers I control and can use SMTP AUTH on, so the issue of sending mail from networks not 'allowed' to send mail for a given domain isn't an issue), there are other problems with its current implementation http://homepages.tesco.net/~J.deBoynePollard/FGA/smtp-spf-is-harmful.html Outlines some of the problems with it, and the most important ones (IMO) I'll summarise here: It uses TXT records for it's database. This is a bad implementation choice, and may cause problems later on. Use of TXT records makes it seem like yet-another-hack-to-get-around-spam. It relies on DNS for security and propagation. DNS in its current state isn't overly secure, although it has the ability to be. We've all seen DNS propagation problems. Maybe these are social problems that can be overcome with better education - maybe we'll still have people not caring and not implementing things properly, and it'll just make everything worse. SPF doesn't actually address unsolicited bulk email. It won't stop mail being sent by machines infected with viruses or worms - they will be sending mail using their legitimate domain. It won't stop the big spammers who spam with their ISPs consent (perhaps anecdotal, I've heard this from a few people though). All it does is stop other people using your domain to send spam from. Maybe that's good enough on it's own merits, but it's not the spam killer you might think it is. The May Linux Journal had an article on SPF as well, although I didn't read it well enough at the time to discuss. They were very much in favour of it, from what I remember. I'm all in favour of technical solutions that will make this harder for spammers, but I'm not sure SPF is going to help a hell of a lot. That said, I don't have a better answer.