The attempt to standardize SPF in the IETF collapsed -- "imploded" is a
better word.  The resulting RFC, 4408, is Experimental rather than
standards-track.  I haven't read it in enough detail to know if my
objections have been dealt with, but see the IESG note at the beginning.
However, it inherently breaks mail forwarders, makes it difficult for
people to do mail-forwarding (Section 9.3 of 4408 is pretty bad), and
makes it hard for people who do use other mail senders.  (As an example,
this very piece of email did not originate from my employer's mail sending
machine, for good and sufficient reason.)

If you want to do something SPF-like but done right, you want DKIM, which
is working its way through the IETF now.  It does cryptographic
authentication of the sender, and permits fine-grained delegation.  It
still has the major problems I've identified below.

The most important reason not to use SPF or DKIM, though, is that as
anti-spam mechanisms they simply don't work.  Spammers create many new
domains, use them for a day or so, then abandon them.  In fact, they
populate their zones with SPF records.  What, precisely, are they good
for?  Let me put it another way -- how much of the spam you receive would
have been blocked because it impersonated some zone you know, rather than
coming from some domain you've never heard of?

Yes, it prevents joe jobs.  That's a minority of spam.  It helps more
against email-spread worms, a bit more of an advantage, and it certainly
helps with blow-back from such worms.  *Maybe* it's useful against
phishing, though I have serious doubts for reasons I won't go into here.
 ee http://www.cs.columbia.edu/~smb/papers/phish-risks.pdf for a longer
essay on the inherent problems.