[cd34]

Well, having read those two pages, there are so many incorrect assumptions that are made.

They claim it breaks fallback MX servers. SPF doesn't look at the path that email took, merely that the email's envelope came from an IP that the published record says is valid. I know of no ISPs that use someone else's SMTP servers as a relay for their outbound mail. When you connect with DSL, I seriously doubt comcast.net is sending out a mailserver in the dhcp setup that specifies another ISPs SMTP server.

But, in my opinion, I do not agree with either of those author's assumptions. If you set an SPF record that says bellsouth.net is allowed to deliver mail that you originate from domain.com, and someone submits a spam report to bellsouth.net saying, this email came from you. A quick look at the headers would say, no, it didn't come from bellsouth. A secondary check of the SPF record would say, not only did it not come from bellsouth, but, the SPF record says if it didn't come from bellsouth, its invalid.

There are ISPs in Europe that refuse to take email unless the domain is properly tagged with SPF. Yahoo, while they have their domainkeys method, do set an SPF-Fail flag in their spam checking that tilts their spam meter in the other direction. However, with a valid SPF record, their filters are a little looser. Hotmail also uses SPF forgeries as a scoring point. We look at SPF only as a check, but don't make any determinations. An SPF fail doesn't prevent email from being delivered, but, I can tell you that of the mail I have received with the SPF flag having failed, 100% of it was spam. That isn't to say that I didn't get spam with a valid SPF record.

There are conditions where SPF will not work well, and remailing/mailing lists is one of them.

There are very few real ways to stop spam and while this isn't the best method, I have found that the incidence of domains getting hit with the backscatter for spam has dropped dramatically once SPF records were implemented.