How do you fix “SPF softfail”?
Updated July 3, 2026
SPF softfail means the sending server's IP isn't authorized by your SPF record, and your record ends in ~all, which tells receivers “treat this as suspicious, but don't reject it outright.”
Why this happens
The last mechanism in an SPF record (the “all”) sets the default verdict for any IP the record doesn't list. ~all (tilde) means softfail: unauthorized mail is accepted but flagged, typically nudging it toward spam. -all (hyphen) means hardfail: unauthorized mail should be rejected. ?all is neutral and says nothing, and +all authorizes the entire internet. Never use it.
If your own mail is softfailing, the real problem isn't the ~all. It's that the sending IP isn't in your record. Some service is sending as your domain without being listed: a new marketing tool, an app server sending directly, or a provider whose include you never added. The ~all just determines how gently receivers treat the miss.
There's a persistent myth that ~all is “unsafe” and everyone must move to -all immediately. In practice, DMARC has made the distinction less dramatic: with a DMARC policy, what matters is whether SPF passes with alignment, and your DMARC policy, not the all qualifier, decides what happens to failing mail. Many experienced operators keep ~all specifically because -all can cause overly aggressive rejection of forwarded mail at SPF-checking receivers before DMARC evaluation even happens.
How to fix it
- 1
Find the IP that softfailed
Get the Authentication-Results or Received-SPF header from an affected message. It shows the client IP that wasn't authorized. If you're seeing softfails in DMARC reports instead, note the source IPs there.
- 2
Decide if that source is legitimate
Look the IP up. If it belongs to a service you actually use, it needs to be in your SPF record. If it's unknown, it's likely spoofing or a forwarder: spoofing is your DMARC policy's job, and forwarding can't be fixed with SPF at all.
- 3
Add legitimate sources to your SPF record
Add the provider's documented include: (or the server's ip4: address) to your record. One record per domain: if you already have an SPF record, edit it rather than adding a second TXT record, which is itself an error. Re-check your DNS lookup count stays at 10 or fewer.
- 4
Choose ~all or -all deliberately
If you have DMARC at p=quarantine or p=reject, ~all is fine: DMARC enforces the policy, and softfail still counts as an SPF fail for DMARC purposes. Consider -all only once your DMARC reports show every legitimate source passing for several weeks, because -all makes any SPF miss immediately punishing.
- 5
Verify the fix
Run your domain through our SPF checker to confirm the record is valid and the new source is covered, then send a test from that service and check for spf=pass in the received headers.
Verify the fix
Run the check that corresponds to this error. You'll see the same red/amber/green verdicts mailbox providers effectively apply.
Open the SPF checker →Preventing it next time
Softfails from legitimate sources mean some tool is sending as your domain without authorization, and every new SaaS your team adopts is a fresh chance for it to happen again. DMARCPath watches your aggregate reports and flags new sources softfailing SPF the day they appear, so you authorize them (or shut them down) before deliverability suffers and before a customer finds your mail in spam.
Frequently asked questions
- Is ~all bad? Should I switch to -all?
- ~all isn't bad. With a DMARC policy in place, softfail still counts as an SPF fail for DMARC, and DMARC's policy governs the outcome. Move to -all only after your DMARC reports show all legitimate mail passing. It makes mistakes more expensive, not your domain more secure.
- Does softfail send my mail to spam?
- Sometimes. Softfail is one negative signal among many; receivers weigh it with content, reputation, and DKIM. Mail that softfails SPF but passes aligned DKIM usually delivers fine. Mail that fails both often doesn't.
- Why does forwarded mail always softfail?
- Forwarding delivers your message from the forwarder's IP, which is never in your SPF record. SPF fundamentally can't survive forwarding. That's why DKIM matters: its signature travels with the message regardless of which server delivers it.
Catch this before your customers do
DMARCPath watches your domain's authentication continuously and alerts you the day something breaks, not the week a customer mentions your emails stopped arriving. One domain free.
Start monitoring free →