SPF SoftFail (~all) medium
SPF SoftFail (~all) — Mail Marked Suspicious
The sending IP isn't in your SPF record, so ~all returns SoftFail — accepted but pushed toward spam.
What you see
Received-SPF: softfail (google.com: domain of transitional [email protected] does not designate 198.51.100.7 as permitted sender) spf=softfail (sender IP is 198.51.100.7) smtp.mailfrom=example.com
What’s actually happening
Mail doesn't bounce, which is exactly why this one hides. Messages land in Junk or Spam for some recipients and the Inbox for others, with no error in your logs because the receiver accepted the message. You only notice when someone says 'I didn't get your email — oh, it's in spam.' The Authentication-Results header on a delivered message shows spf=softfail.
Common causes
- You added a new sending source — a CRM, a transactional ESP, a new mail server — and never added its include or IP to the SPF record.
- A marketing platform sends on your behalf from IPs that aren't authorized in your record.
- You inherited a record ending in ~all that only ever listed your old on-prem server.
- A subdomain sends mail but has no SPF record of its own, so it falls back to a parent record that doesn't cover the actual sender.
- DNS propagation lag right after editing the record — the receiver is still seeing the old version.
How to fix it
- Find every system that sends as your domainList them all: Google Workspace or Microsoft 365, your transactional provider (SendGrid, Postmark, SES), marketing tool, helpdesk, invoicing software, on-prem relays. SoftFail almost always means one of these isn't in the record.
- Add the missing source to a single SPF recordAppend the right mechanism — include:_spf.google.com, include:sendgrid.net, ip4:198.51.100.7, etc. — to your one v=spf1 TXT record. Do not create a second SPF record; that causes a PermError (see related).
- Watch the 10-DNS-lookup limitEvery include:, a, mx, and redirect counts toward SPF's hard cap of 10 DNS lookups. Blow past it and you get a PermError instead of a pass. Flatten rarely-changing includes to ip4/ip6 if you're near the limit.
- Decide whether to harden ~all to -all~all (SoftFail) is the safe default while you confirm coverage. Once you're certain every legitimate source is listed, switching to -all (HardFail) tells receivers to reject unauthorized mail outright — stronger protection, but only flip it after verifying nothing legitimate still fails.
- Re-test after DNS propagatesSend a message to a Gmail account, open 'Show original,' and confirm spf=pass with your sending IP. Or use a check-my-SPF tool against the live record. Allow up to your TTL for the change to take.
Stop it recurring
Every time you onboard a new tool that sends email as your domain, update the SPF record in the same change ticket so a source is never left out.
Related errors