Email system experts are divided on the issue of whether SPF ( and Microsoft's "me-too" variation dubbed CallerID and later SenderID -  trademarks of their respective owners) is a "good thing" or a "bad thing." The division is probably not 50-50.

Several prominent experts are vehemently against designated sender schemes such as SPF. Predictably, creators and supporters of SPF staunchly defend it while also stating it is only an anti-forgery solution -  and does nothing for stopping spam that is not forged.

But let's say you don't care about the theories - only about whether  an SPF (or SenderID) record will help get your mail through - or worse - cause legitimate mail from you to be mistaken as a forgery or labelled as spam.

The bad news is that even if an SPF record helps get your mail delivered to Microsoft Hotmail or MSN email users - an SPF record may hurt your email's spamminess score elsewhere, at hundreds of thousands of non-Microsoft mail services.

Many email administrators who are against SPF state that they consider an SPF record a strong indication that the email is spam, simply because they say that the majority of emails which PASS the SPF test do come from opt-out spammers. Even tho the creators of SPF clearly state that the SPF record is only to be used to detect forgery - they cannot control what any email administrator chooses to do with the information.

In desparation or perhaps vengefulness, email administrators may use any characteristic that is "popular with spammers" at the moment - to reject or mark mail with that characteristic as probable spam. I personally disagree with this kind of logic - which is why I personally do not like or use Bayesian anti-spam filters like Spam Assassin. But literally millions of email recipients worldwide have their mail filtered through this and other freely available open source and "better than nothing" systems.

For the moment, let's say that we support SPF and think its wonderful and the right thing to do. All the email admins in the world magically decide they love it and will favor SPF when humanly possible.  There are still four dramatically pervasive ways in which an SPF record can prevent priority delivering of your email:

1. Filters which do machine learning - learn that there is a high correlation between the SPF=PASS factor and spam. Mail with SPF=PASS scores lower automatically, even tho the humans administering want SPF to be a good thing. Of course the humans can artifically prevent the machine learning from using the knowledge about SPF.

2. When the mail you send is "account forwarded", and the destination ISP checks your SPF record - your mail will appear to be a forgery. It "shouldn't" work this way - but unless and until everybody does what they should - it does. Any ISP that uses SPF checking SHOULD either disallow inbound forwarded accounts OR skip SPF checks on accounts that are forwarded. But they don't. I placed into the public domain in August of 2004 - a simple solution for the SPF forwarding problem, which has not been widely publicized or discussed yet. For this article, the point is that there is a lot of forwarding going on around the world which will affect deliverability of your email if you have an SPF record - even if it "shouldn't be that way."

3. Non-malicious forging - send an article from the Washington Post, or a greeting card, Paypal payment, email from within ebay, or an invoice from Intuit to your customer to name but a few - and unless you authorize all these and more in your SPF record - it will be received as a forgery. All responsible sites COULD fix this practice with relative ease so that it would not break SPF Classic, with no loss in intended services. But they haven't. To keep from breaking SenderID (hmm is that even possible) the services mentioned would lose functionality, because SenderID uses the header-from not just the envelope-from.

4. You travel, move between different offices, different ISPs or stop off at Starbucks and latch onto a hotspot somewhere. Unbeknownst to you, your port 25 email send to your SPF authorized server is hijacked and put thru the Joe's Hotspot outbound server. At the other end, your email appears to be a forgery because of your SPF record. (You could avoid this by using port 587 to send, if your corporation / ISP supports the official submission port 587 - and if you can make sure everyone on your domain uses it exclusively.)

CONCLUSION:

Some of our customers are taking our recommendation to create a "Microsoft only" branch of their email list, and assign a completely separate email address domain with a SenderID or SPF record, only for sends to MSN, Hotmail, and Microsoft addresses. That way they can keep their existing email address domain free of the potentially stigmatizing SPF record for the rest of the world. I don't think Microsoft will stick with their demand the senders have a SenderID record over the long term anyway, but if you take them seriously this may be an option to consider.

Quoting an article by Ray Everett-Church: "as corporations try to decide whether to give SPF a try, the fastest growth in SPF adoption is among the ranks of, you guessed it, spammers! According to a report by email technology firm CipherTrust, the average spam email they examined is three times more likely to pass an SPF check as compared, with 34 percent more spam using SPF records than non-spam."

I don't follow the math but the same trend is reported by everyone I know who studies their SPF check results. When I followed Ray's link to the CipherTrust report - it appeared to me that CipherTrust was trying to show how dramatically successful SenderID really is - a whopping 3% of spam fails SPF check - they saw this as a 230% improvement over the previous less than one percent. I am guessing that Ray got to read their entire report and put a more practical, yet opposite spin on the numbers.

My opinion is that SPF is trying to do too much. There probably is a place for simple indications of authorization to send email in DNS records, and SPF Classic could have been the hero in this niche. But it needs to be simple and have a stable definition, which SPF has not.

The association with Microsoft probably hurt the SPF cause rather than helping it. One reason I didn't attempt to evangelize my public domain solution for the forwarding problem  was that it came at a time where it might have helped SenderID as they pressed their case - and if I wanted to help anything - it would be SPF Classic, not an even worse abuse of DNS such as bloated XML in a TXT record.

Meng Wong has always said that a reputation system would be needed in addition to SPF or as we would put it - in combination with SPF. IE inbound email servers cannot depend on an  SPF PASS or FAIL without third party data in addition. Not just as a separate score - but actually combined in the same test with SPF.

(The IETF MARID - Mail Authorization Records In DNS group of which I'm a long term member, investigates them all - well at least each member continually puts forth his or her pet proposal :) - I'm not sure there's been much movement.)