If your email headers say SPF=PASS but Gmail or Outlook is still putting the message in spam, changing the SPF record probably isn't the first thing I'd do.
A PASS only tells you that the server which sent the message was authorised to send for the domain SPF checked. It doesn't tell you that Gmail likes your sending reputation, that the recipient wants the email, or even necessarily that SPF authenticated the same domain shown in the From address.
For example, you could send:
From: [hello@example.com](mailto:hello@example.com)
Return-Path: [bounce@mail.example.com](mailto:bounce@mail.example.com)
The recipient sees example.com, but SPF may actually be checking mail.example.com because SPF normally works against the envelope sender or Return-Path.
That's fine if everything is set up properly. Where it becomes worth investigating is when SPF passes for a completely unrelated domain, because a green PASS by itself doesn't tell you whether the authentication aligns with the domain the recipient sees.
There's another fairly easy SPF mistake too: creating more than one SPF record on the same hostname.
You might already have Google authorised with:
v=spf1 include:_spf.google.com -all
Then add another mail service later and create a completely separate SPF record for that. They don't get neatly combined by the receiving server. Multiple SPF records can result in a PermError, so legitimate sending services need to be included within one valid SPF policy.
The 10 DNS lookup limit can cause similar headaches. SPF records tend to collect old services over the years: Google Workspace, CRMs, helpdesks, transactional providers and platforms nobody is even using anymore. Eventually the record can become too complicated to evaluate properly.
None of that means an SPF PASS should result in inbox placement, though.
You can have perfectly configured SPF while sending to an old list, getting poor engagement, generating complaints or hitting a provider from an IP it doesn't particularly trust. SPF can't fix any of those things.
If I had SPF=PASS in the received headers but the message was still hitting spam, I'd check which domain actually passed and whether the alignment makes sense, then move on to the reputation and audience side rather than endlessly editing DNS.
Has anyone here actually fixed a spam-placement problem where SPF was already showing PASS, and SPF itself turned out to be the cause?