SPF softfail: what ~all really tells receivers, and when it becomes a problem

Q: Should I use ~all or -all in my SPF record?

For domains that send mail, ~all plus an enforced DMARC policy is the common modern posture: DMARC provides the enforcement while ~all avoids hard-bouncing legitimately forwarded mail. Reserve -all for parked domains that send nothing at all.

2026-09-10

The SPF specification is unusually honest about softfail. RFC 7208 defines it as a statement that the domain owner believes the sending host is not authorized but "is not willing to make that strong policy statement" a hard fail would be. A hedge, in other words, written into the protocol on purpose. Understanding softfail means understanding why a domain owner would want to hedge, and why so many SPF records end in ~all rather than the harder -all.

If you're here because a header or a checker showed spf=softfail, there are two different situations that produce it, with two different fixes. We'll take the mechanics first, then the diagnosis.

The four qualifiers, and where softfail sits

Every mechanism in an SPF record can carry a qualifier, and the one attached to the final all term declares the domain's default for any server not matched earlier:

+all — pass everything. An open door; never use it.
?all — neutral. The domain declines to state an opinion.
~all — softfail. Probably not authorized; accept the mail but treat this result as a mark against it.
-all — fail. Not authorized; the domain invites rejection.

So v=spf1 include:_spf.espmail.net ~all reads: mail from my ESP's servers passes; mail from anywhere else, be suspicious but don't bounce it on my say-so. The spec tells receivers not to reject a message on softfail alone, though they may subject it to closer scrutiny, a gentler instruction than fail's, and in practice major providers treat a lone softfail as one weak signal in a larger filtering decision, not as grounds for refusal.

Why softfail exists: the forwarding problem

The hedge is not cowardice; it is a rational response to SPF's known blind spot. SPF checks the connecting server's IP against the domain's list, and forwarding puts legitimate mail on IPs the domain owner cannot list. A message you sent perfectly can arrive at its final destination from a university relay, an alumni forwarder or an old mailbox's auto-forward rule. Under -all, a strict receiver may reject that mail outright. Under ~all, it survives with a demerit.

That is why ~all became the working convention for sending domains, and why the "upgrade to -all" advice you'll see in hardening guides deserves context. In the era of DMARC, the enforcement decision has largely moved up a layer: DMARC only counts SPF as a pass when the result is pass and the domain aligns, so softfail and fail land identically at DMARC evaluation, and the domain's DMARC policy, not the SPF qualifier, decides the message's fate. With DMARC at enforcement, ~all versus -all changes little for aligned mail streams. The main population still served by -all is domains that send no mail at all, where there is nothing legitimate to forward and no reason to hedge.

Situation one: softfail on mail that isn't yours

The healthy case. Your record says ~all, someone spoofs your domain from an unauthorized server, receivers evaluate SPF and record softfail. The mechanism is working as designed. You will see these events in your DMARC reports as failing rows from IPs you don't recognize, and the correct response is at the DMARC layer: move toward quarantine and reject per the staged method in how to set up DMARC, so the hedged SPF verdict stops being the only thing standing between a spoofer and your recipients' inboxes.

Situation two: softfail on your own legitimate mail

The misconfiguration case, and the one that brings most people to this page. A message you genuinely sent shows spf=softfail in its Authentication-Results header. Since softfail means "matched nothing but the ~all," the diagnosis is always the same: the server that sent this message is not in your SPF record. Common routes to that state:

A missing include. You added a new sending service, a CRM, a support desk, a billing system, and never added its include: to your record.
The wrong domain carries your record. SPF is evaluated against the envelope sender (return-path) domain, which on many platforms is a bounce domain like bounce.yourdomain.com. If the record lives on the wrong host, your real mail matches nothing.
A copy-paste record from another environment, listing the old ESP's servers but not the current one's.
Forwarding en route. The recipient's address silently forwards to another mailbox, and the final hop sees the forwarder's IP. Nothing on your side is broken; DKIM, which survives forwarding, is what keeps DMARC passing on that path.

The fix for the first three is mechanical: identify the sending service's documented include, add it, and re-verify. Paste your domain into the SPF checker to see the record receivers actually fetch, and use the SPF generator to rebuild it cleanly if it has accumulated years of cruft. While editing, watch the protocol's budget: every include spends DNS lookups against the ten-lookup limit, and blowing that budget converts your softfails into the far worse permerror.

How much softfail actually hurts

Ranked honestly against everything else in why emails go to spam, a softfail on your own mail is a moderate problem with an outsized signature. On its own it rarely spam-folders mail from a sender with solid domain reputation. But it silently fails the SPF half of DMARC, leaving DKIM as your only aligned proof; if DKIM then hiccups, your mail fails DMARC entirely. And under Google's and Yahoo's bulk-sender rules, summarized on our Gmail and Yahoo requirement pages, authentication that works is an entry condition, not extra credit. Treat a softfail on legitimate mail as a defect to fix this week: cheap now, expensive when it compounds with the next problem.

Verifying the fix

DNS edits deserve verification from the receiving side, not the publishing side. After updating the record, send a real message to a mailbox you control at a major provider, open the raw source, and read the Authentication-Results line with the email header analyzer. You want spf=pass with your envelope domain named, and dmarc=pass alongside it. A full-stack check with the email authentication checker closes the loop, and the email deliverability score confirms nothing else in the setup layer is waiting to be found.

Related guides

SPF permerror — the SPF result that means the record itself is broken
SPF too many DNS lookups — the budget your fix must stay inside
SPF checker — see the record receivers fetch, with per-mechanism evaluation
SPF, DKIM and DMARC explained — the three protocols softfail lives inside
DMARC reports — where softfail events on your domain become visible
SPF alignment — why a pass can still fail DMARC

About this guide

Written by InboxRatio Editorial. Softfail semantics are drawn from RFC 7208 directly; receiver treatment is described per the major providers' published sender documentation, and where behavior is convention rather than specification, it is labeled as such. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on the SPF specification and provider documentation rather than our measurements; the testing protocol is documented in how we test and our source rules in sources.

Last updated

10 September 2026. Specification references and provider treatment reviewed quarterly.

Frequently asked questions

What does SPF softfail mean? The sending server matched nothing in the domain's SPF record, and the record ends in ~all: the domain believes the server is probably not authorized but asks receivers to accept the message and merely treat the result as a suspicious signal, per RFC 7208.

Is SPF softfail a pass or a fail? Neither, deliberately. For filtering, receivers treat it as a weak negative signal. For DMARC, it is not a pass, so it cannot satisfy DMARC's SPF requirement; only spf=pass with an aligned domain does that.

Should I use ~all or -all in my SPF record? For domains that send mail, ~all plus an enforced DMARC policy is the common modern posture: DMARC provides the enforcement while ~all avoids hard-bouncing legitimately forwarded mail. Reserve -all for parked domains that send nothing at all.

Why is my own email getting SPF softfail? Because the server that sent it is not in your SPF record: a missing include: for a sending service, the record published on the wrong (envelope) domain, or an intermediate forwarder. Run the SPF checker and compare its server list against everything that legitimately sends for you.

Does softfail mean my email goes to spam? Not by itself, at most providers. It weakens your authentication posture, fails the SPF leg of DMARC, and stacks with other negatives. Senders with good reputations usually survive a stray softfail; senders with marginal reputations don't have that luxury.

How do I fix SPF softfail? Identify the unmatched sending IP from the header or DMARC report, add the responsible service's documented include to your record, stay under ten DNS lookups, and verify from a real delivered message's headers that the result reads spf=pass.

Softfail is the protocol shrugging. Make sure it only ever shrugs at mail that isn't yours: two minutes with the SPF checker tells you which side of that line your record is on.