Basically SPF is designed to verify that the *ip address* sending an email to an smtp server is "compliant" with a proper *enveloppe*. The enveloppe does not appear in the content of an email.
There are several big problems with this:
a) only the enveloppe is verified, and the enveloppe does not show in the emails in your mailbox, so it does nothing against phishing etc.
b) since it can be very problematic to block ip addresses the spec implements a "soft fail" feature which basically allows bypassing the spf checks. Millions of domains have no spf records, or have records allowing "soft fail". So it is very easy for spammers to pass spf checks.
DKIM / DomainKeys do not check ip addresses nor enveloppes, only headers and body of emails. The big issue ( imho ) with them are:
a) implementation costs for sender. Far from trivial, many buggy/crappy tools and libs here and there, few efficient implementations, and a configuration is required per domain on each server which will send your emails..
b) cpu costs for the sender. If you send many emails, it is very expensive in terms of ressource to compute these signatures
c) few recipients check these records anyway. Yahoo and Gmail does, but not hotmail, aol, outlook ..
d) Anyway, a lot of spam and fishing emails are sent with perfect DKIM / Domain Keys records. You just have to send these emails via yahoo or gmail. And *lot* of spam is sent via these accounts. Nothing prevents from sending an email which *looks* like coming from Paypal:
From: <firstname.lastname@example.org> Paypal Security
Will "look" coming from paypal and will have DKIM + DomainKeys + SPF all perfectly verified.
Paris, because I write from there.