Heya. I found this thread while looking for some other SPF info, and just thought I'd add my thoughts.

I think it's best if you first understand exactly what SPF does. It compares the purported sender of an email (the "from" address) with a list of allowed servers for that domain. If you get an email from [email protected], it checks with aol.com to see if the server that the message came from is an allowed server.

That's all it does. When an email says it's from a certain domain, it checks to see if it really came from a mail server for that domain. Without actually adding SPF or anything else, you can actually do a really basic check like this. Simply look up the MX record(s) for the domain, and compare that to the server that sent the email. The Sender Verification Extension for Thunderbird actually does this for domains that don't have SPF records. Some pre-SPF spam filters do this as well.

There are no downsides to implementing SPF, other than a few DNS queries. Well, that and making sure that you have the correct SPF entry to cover all your servers.

However, there are also no real benefits to you from implementing SPF for your domain (which is probably part of the reason it isn't more widely used). Adding SPF to your domain benefits people who receive mail from your domain (or mail that claims to be from your domain). When eBay or OnlineBank_01 add SPF records, that makes it very easy to tell that the phishing email from dsl1-2-3-4.dynamic.bigisp.com isn't actually from eBay.com or OnlineBank_01.com.

It doesn't really add anything new for geeks, who can pull the IP from the headers and figure out if it came from a legitimate server or not. It does let the sending domain specify a little better what is and isn't allowed, but that's about it. However, standardizing the SPF format allows a user to see (via a program on the mail server or in their email client) whether or not the email came from a valid IP, without having to know what an IP, MX, or email header is.

They're working on getting their own DNS record type, but for now it works just fine using a TXT record. That means that anyone with access to their domain's DNS can implement it. It doesn't require any major changes to any part of the email system. I've heard of two ways to "hack" SPF. The first is using two domains which include each other. When the recipient tries to check the SPF, it goes into a loop. That's easily fixed with some sanity checking and/or a simple timeout on the check to prevent a total DoS. The other involves DNS poisoning to return a different record. That's pretty involved for simply forging an email...

The SPF site has a script that will even accept the parameters to tell you about why an SPF decision was reached. http://spf.pobox.com/why.html?sender...recvdomain.com That can easily be included in any sort of bounce message to explain to the end user why an email was rejected. They don't have to try to get in touch with the domain's admin and figure out why it was blocked and how to go about fixing it. It's all pretty much self-explanatory.

invisibill.net really doesn't get forged that much. For me, universal adoption would mostly stop all the replies I get to viruses that "I sent". Since all the emails "from me" would be coming from sources that are not in my SPF record, it would be known immediately that they're not really from me.

It doesn't stop lookalike domains (paypa1.com, etc.) from creating SPF records that allow every single IP address. It doesn't do anything if the receiver doesn't actually check their incoming emails against SPF records. It doesn't really help you at all, unless spoofs using your domain are a big deal. It's mostly to help people receiving mail from your domain verify that it came from an allowed server.