SPF

SPF has been pretty hotly debated lately. It seems that the first major objection is that it doesn't actually block spam. As spammers are registering their domains, they are setting up SPF records so SPF is giving it's "stamp of approval" in the mail filtering process.
SPF wasn't designed to stop that kind of thing. It is designed to help companies like aol, hotmail, yahoo, and really everyone who has spammers using from addresses at their domain. SPF ensures that a domain owner can specify what mail servers are allowed to send mail from that domain, period.
Another big problem cited is that people will screw up their SPF records. This is a problem. Sourceforge had their records messed up for about 5 days in November. During that time, at least my mail server was bouncing all messages that came from them to my customers. The reality is that Sourceforge told my server that there were no authorized senders for their domain, and my mail server honored their request. If I screw up my MX records and point them to some other domain and all my email gets lost, I do not get upset at owner of the sending mail server, not do my customers, they get upset at me, as it was my mistake.
Then there is the travelling salesman problem. If I am a salesperson for xyz and I'm on the road trying to send email out, often I will either by choice or by transparent proxy, be using my ISP's outbound mail server. When I send an email out, it originates from my ISP, not from my company's mail server, and hence gets blocked by SPF. The best way around this is to use an smtp over ssl connection to an alternate port, like 465 or 587 back to the company's mail server. ISP's usually will not proxy those ports.
There are other challenges that pop up from using SPF, like remailers. Most of the problems have solutions, though not necessarily elegant ones. The reality is that the world is going in this direction, so the solutions will become more refined and tolerable as time goes on.

On the upside, in addition to assuring a receiving mail server that mail from your domain is coming from an authorized source, it does a great job a blocking certain types of spam, and many types of viruses. A common spamming technique is to set the "from" address to match the domain of the recipients, because mail servers are normally configured to treat mail from their domain differently, and hence it is more likely to make it to someone who will read it, and the person getting it is more likely to open the email since it "appears" to be from inside their organization. Many contemporary viruses use the same logic to get into an organizations mail system and increase the likelihood of it being opened and spread.
Publishing SPF records and setting up filtering on SPF information very effectively eliminates both of those two nusiances.

In the end, it is a judgement call on whether or not to implement SPF. There are really 3 ways to approach it:
Ignore it
Implement SPF and block non-conforming email
Implement SPF and use it to feed into an anti-spam system, like spamassassin, as a factor in determining whether the email should be passed, dropped, tagged, etc.

I hope this helps some.