It has been known since the original design of SPF that it could only provide some additional information in determining whether or some something is spam. Indeed there are many common circumstances that can lead to a false fail.
Forwarding breaks SPF and causes false fails
For example, suppose I have an email address that I don't use, say, [email protected], and I set it up to forward all mail to my real address, [email protected]. Now if Wilma sends me email from her system, foo.example and that is all valid in terms of SPF, it will still be still come into domain.example mail server from example.tld's mail server. example.tld's mail server is not going to be authorized under SPF for mail from foo.example even though there is no forgery or spam happening.
Now there are a couple of things that people can do to try to clear up cases like this. For example domain.example can whitelist example.tld. Alternatively different forwarding mechanisms can be set up. But none of these are ideal, reliable, or even available for all configurations.
Don't block when you know false fails are possible
Given the above (and some other ways to systematically get false SPF fails), it is important to weigh the information an SPF failure gives you instead of automatically rejected all SPF fails. Fortunately, even longer than SPF has been around, anti-spam mechanisms have used bayesian filters. This is more than just giving a score to each factor, it is a way of combining all of the little facts the system knows about what is and isn't spam and balancing that all out into a judgement that will bias toward false negatives (letting some spam through) instead of false positive (rejecting things that shouldn't be rejected).
SPF is terrible, but was necessary
I participated in some of the early discussions that lead to SPF. Everyone involved knows it is deeply flawed. But we were desperate for anything that would help control the flood of spam into the mail servers we were running. (Sure, individual users hate spam in their inboxes, but the people who run mail systems have to pay for real hardware and bandwidth to deal with all of the incoming mail even if most of it is filtered before it reaches your mailbox.)
DKIM largely supersedes SPF. I've been out of the email management business for a while, so I'm not entirely sure what the current state of thinking is on why SPF persists now that DKIM is more widely available. I can see cases where SPF is possible and DKIM isn't. For example, with SPF you can authorize a domain or network as a sender without having to give that sending domain your DKIM private key. SPF and DKIM place different requirements on the legitimate sending domains to coordinate their activity.
But still, I'm surprised to see that SPF is still around. At the time it was introduced I thought of it is a temporary desperate measure that would be replaced by somewhat more coherent mechanisms. But it appears to still have a role to play.
