spf=softfail

A receiver checked your SPF record, could not find the IP that sent the message, and your record ends in ~all — so it reports a soft fail. Here is why, what it costs you, and how to authorise the right sender.

Check your domain free → Jump to the fix ↓

What it means

The cause.

spf=softfail is an authentication result, not an SMTP error. It appears in the Authentication-Results header a receiver stamps on your message. It means SPF ran, the IP that connected was not listed by any mechanism in your record, and the record ended in ~all (soft fail) rather than -all (hard fail). RFC 7208 defines soft fail as a weak statement that the host is probably not authorised — the domain is not confident enough to ask for an outright rejection.

The result is caused by a sending source you have not added to your SPF record. A new marketing platform, a CRM, a helpdesk, a payment provider or a server that relays mail on your behalf connects from an IP your record does not cover, so SPF cannot match it. The ~all at the end tells the receiver to treat that as suspicious rather than failed outright, which is why the message still arrives but carries a soft fail.

It is worth separating the result from the misconfiguration. spf=softfail is what the receiver reports; the underlying problem is a legitimate sender missing from your record, or a stale record that no longer reflects who sends your mail. Fixing the report means authorising the real sender, not switching ~all to -all to make the wording change.

Why it matters

The impact.

A soft fail rarely bounces on its own, but it does not authenticate you either. Receivers commonly fold it into their spam scoring, so mail can slip from the inbox into the spam folder without any hard rejection to explain why. Because SPF did not pass, it also cannot align for DMARC on that message.

That DMARC gap is where soft fail costs you most. DMARC passes only when SPF or DKIM passes and aligns with your From: domain. If a message was relying on SPF to satisfy DMARC and SPF soft fails, that leg is gone — and since 2024 Gmail, Yahoo and Microsoft require DMARC to pass for bulk senders. If DKIM is not also passing and aligned, the message fails DMARC and is filtered or rejected under your published policy.

What to do

The fix, in order.

Work top to bottom, then re-check — DNS changes take a few minutes to take effect.

1 Confirm which IP triggered the soft fail. Open the message headers and read the Received-SPF or Authentication-Results line. It names the sending IP and the domain that was checked. That IP is the source your SPF record does not yet cover — you are fixing that specific sender, not the whole record.
2 Identify the sending service. Match the IP to the tool that sent the mail: your email platform, CRM, helpdesk, invoicing tool or a relay server. Find that provider's published SPF include or IP ranges in their documentation — nearly every sending service publishes one.
3 Add the sender to your existing SPF record. Put the provider's include: (or its ip4:/ip6: ranges) into your single v=spf1 record, before the all mechanism. Do not create a second SPF record — two records is itself a permanent error. Keep everything in one record with one v=spf1 and one all.
4 Keep ~all unless you are ready to enforce. Soft fail is a reasonable default while you are still discovering senders. Do not switch to -all to silence the wording — that turns a soft fail into a hard fail and can bounce legitimate mail you have not authorised yet. Move to -all only once every sender is in the record.
5 Set up DKIM and DMARC so SPF is not your only leg. Enable DKIM signing on the same sending service and publish a DMARC record. With DKIM passing and aligned, an occasional SPF soft fail — for example on forwarded mail, where SPF often breaks — no longer decides DMARC on its own.
6 Re-check after DNS propagates. DNS updates take a few minutes to spread. Run your domain through the SPF checker to confirm the new IP is now covered, then send a test through that service and read the headers again — you want spf=pass, not softfail.

Confirm the error is gone.

Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.

Check your domain → Or send a test email

Common questions

About this error.

What does spf=softfail mean? It is an SPF authentication result reported by the receiver. SPF ran, the IP that sent the message was not listed in your record, and your record ends in ~all. RFC 7208 defines soft fail as a weak statement that the sender is probably not authorised — accepted, but treated as suspicious.

How do I fix spf=softfail? Read the message headers to find the sending IP, match it to the service that sent the mail, and add that service's include or IP ranges to your single SPF record before the all mechanism. Do not switch ~all to -all — that hides the wording without authorising the sender.

Is spf=softfail permanent? No. It is a per-message result, not a permanent record error like PermError. It reappears on every message from an unauthorised source and stops the moment you add that source to your SPF record and DNS propagates.

Does spf=softfail send my email to spam? It can. Soft fail rarely bounces on its own, but many receivers add it to their spam scoring, so mail may land in the spam folder. It also means SPF did not pass, so it cannot align for DMARC on that message.

What is the difference between softfail and hardfail? Both mean the IP was not authorised. Soft fail (~all) asks receivers to accept but treat the mail as suspicious; hard fail (-all) asks them to reject it. The qualifier at the end of your SPF record decides which one the receiver reports.

Should I change ~all to -all to fix softfail? Not to fix the result. Changing to -all only converts a soft fail into a hard fail — it does not authorise the missing sender and risks bouncing legitimate mail. Add the real sender first, then move to -all once every source is covered.

Fix the cause, and check it.

SPF checker → Read your live SPF record, count its DNS lookups, and see the mechanism at fault. Google Workspace setup → The exact SPF, DKIM and DMARC records for Google Workspace. Microsoft 365 setup → The SPF line, the two DKIM CNAMEs, and the DMARC record.