I don't recommend using SPF to block incoming email, or to filter it such that it
might end up accepted, unread, and unbounced.
But I hope that, by publishing my own SPF records, those who use SPF for these purposes will
accept and properly prioritize emails that actually do originate from my domains.

Failings of SPF

The reasons I don't recommend using SPF to block incoming email are substantially
and persuasively addressed by Jonathan de Boyne Pollard, who claims
SPF Is Harmful,
though I now disagree with any implications that
IM2000 Internet Mail
is preferable to SMTP
(and yet am "on the fence" with regard to IM2000 compared to SMTP with widespread adoption of SPF).

I do believe forgery is a significant problem on the Internet.
In fact, my email addresses and domain names have often been
"hijacked" by forgers who send spam.
But I consider SPF to be an insufficiently robust design and implementation
to address this problem within the present Internet email system
(which is based on SMTP),
and I'm not convinced any SMTP-based system can (or even should)
be sufficiently secured against forgery.

SPF and similar authentication schemes, such as DomainKeys, can be used to
"tag" incoming email rather than just block it.
A benefit of such tagging might be that incoming mail tagged as "not authenticated"
or "likely forgery" is delivered to a lower-priority "inbox" for a recipient.
As long as the recipient ultimately reads the email and can decide whether it is
worth following up on, improperly tagging email (as a result of any of SPF's problems)
isn't necessarily a big problem.

However, if the result of an improperly tagged email is that the email is
never read and never bounced, a legitimate sender of such email is left believing
either the email has been received and read, or that no email he sends is
necessarily getting through.

And that represents a huge problem with almost any SMTP-based anti-spam
measure, such as SPF: to the extent they increase the likelihood that legitimate
mail is "dropped" (accepted, but never delivered nor bounced back to the sender),
they decrease the sender's confidence in the system and the usefulness of the
bounce mechanism (which is an expensive mechanism in the first place).
Absent some other means of verifying that a message got through
(perhaps in the form of the recipient responding to the message),
SMTP provides no reliable means to verify that a message has not been dropped
(essentially, deleted).

Other problems with SPF and similar schemes include
excessive reliance on the DNS system,
which can increase latencies (add delays) to the receiving of incoming email by
each SMTP server that handles it.

I consider SPF to be just one of many Challenge/Response systems
intended to improve email exchange, all of which degrade it in one way or another
for legitimate use without sufficiently devaluing it for abuse by spammers or vermin authors.