SPF's success (as some form of anti-forgery mechanism for SMTP e-mail) does not depend on near universal publishing of SPF records. Instead what would actually be required would be complete and consistent implementation of SPF at every "peer" recipient site for every site hoping to use SPF as their means of anti-forgery protection. The number of recipient sites, possibly even in ratio to the number of mailboxes at each site, as a true anti-forgery mechanism is almost negligible. Some large recipient sites do use it as an additional measure of trust for a sending site, but never as a true anti-forgery mechanism. Due to the rarity of useful SPF records in the DNS, no site can properly use SPF as a real anti-forgery mechanism without cutting themselves off from all sites which either do not publish any SPF records, or indeed any which publish "wildcard" entries. Indeed in my experience the only time I've found it actually useful to publish SPF records is when I've been explicitly told by some receiving domain that doing so would help increase the acceptance and/or finally delivery rates for my e-mail to their domains. Typically this only applies to bulk mail senders (including mailing list gateways) trying to get mail through to some of the very large e-mail providers who use SPF. However even the smaller lists I operate have not needed SPF records despite having subscribers at these large SPF-using sites. Unfortunately due to another broken-by-design "feature" of SPF this typically results in publishing a totally useless wildcard SPF entry. Certainly this does does help get mail through more effectively and arguably more efficiently to the SPF-using providers, it does nothing whatsoever as an anti-forgery mechanism. In fact it makes forgery even easier for the wildcard'ed domain against any SPF-using recipient. Now if that isn't totally counter-productive, I don't know what is. Indeed due to this second design failure in SPF, it is often recommended (in total ignorance to the facts) that organizations should publish wildcard SPF records, "just in case". What this all says about those large providers who are still using and pushing the use of SPF is hard to say. Perhaps they do reduce the amount of botnet-sourced junk from getting to their customers, but if that's all they're getting from it then they really should look at deploying real mechanisms that could actually stop all botnet generated junk in its tracks instead of pretending that SPF is doing a good enough job because it's obviously not. As others have mentioned, DKIM is the mechanism the standards bodies and their supporters are pushing these days. It's certainly a million times better than SPF. However the only real security for e-mail, and especially for anti-forgery protection, is a true end-to-end PKI-based digital signature mechanism. We've had a very well tested and proven implementation of just this kind of mechanism for a very long time now (very long before SPF in fact): Pretty Good Privacy (PGP). PGP also has the distinct advantage that it is entirely in the hands of the users -- if you want to use PGP with your correspondents then you can do so without needing your e-mail provider to do anything at all but transport your (signed) e-mail. SPF should die out, and should never have been deployed in the first place, because of its fundamental design failures. Sadly many people don't seem to think through the full consequences of this problem and have blindly supported SPF. Unfortunately the whole computer security world is caught up in the absolute stupidity of pretending that throwing one more half-baked security fallacy on top of things is some form of "security in depth". Nothing could be further from the truth. We're being buried in totally useless complexity. * http://www.openspf.org/Statistics * http://spf-all.com/