SPF softfail vs fail: what ~all and -all really change

The last term of nearly every SPF record is either ~all or -all, and every MSP gets asked which one is "more secure." The two give different SPF results, softfail and fail. RFC 7208 asks receivers to treat those results differently, and DMARC (RFC 9989) changes the picture again. Here's how it fits together, along with what Microsoft and Google each recommend, since their advice differs.

What the two results mean

The qualifier in front of a mechanism sets the result when that mechanism matches (RFC 7208 §4.6.2): + pass (the default), - fail, ~ softfail, ? neutral. A trailing all matches everything that got that far, so its qualifier decides the result for every unlisted server.

• Fail (-all). RFC 7208 §2.6.4: "an explicit statement that the client is not authorized to use the domain in the given identity."
• Softfail (~all). RFC 7208 §2.6.5: "a weak statement by the publishing ADMD that the host is probably not authorized." The domain owner "has not published a stronger, more definitive policy."

Neither result means "pass." Both say the server isn't on the list.

What receivers are asked to do

RFC 7208 §8 gives different guidance for each:

• Fail: disposition "is a matter of local policy." A receiver that rejects during the SMTP session SHOULD use reply code 550 and enhanced code 5.7.1. If it accepts the message, it SHOULD add a Received-SPF or Authentication-Results header so later filters can see the fail.
• Softfail: "ought to be treated as somewhere between 'fail' and 'neutral'/'none'." Receivers "SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal." The RFC's examples are highlighting the status in the mail client, or greylisting the message.

So under the SPF standard alone, -all invites rejection and ~all invites suspicion. In practice, most large receivers combine SPF with DKIM, DMARC and reputation instead of acting on SPF alone. That's where the choice gets more subtle.

How DMARC sees softfail and fail

DMARC doesn't distinguish between them. Under RFC 9989, SPF contributes to DMARC only through an aligned pass: an SPF pass for an envelope domain that aligns with the From: domain. A softfail and a fail are equally "not a pass." If the message also has an aligned DKIM pass, it passes DMARC either way. If it has neither, it fails DMARC, and the domain's DMARC policy (p=none, quarantine or reject) describes what the owner wants done.

The catch with -all: rejection before DMARC runs

RFC 9989 §7.1 warns about the effect on DMARC. Because SPF can be checked early in the SMTP transaction, some receivers act on an SPF fail before any DMARC processing happens. The RFC says:

> Domain Owners choosing to use "-all" to terminate SPF records should be aware of this and should understand that messages that might otherwise pass DMARC due to an aligned DKIM-Authenticated Identifier could be rejected solely due to an SPF fail.

It adds that mail rejected this early "will never appear in aggregate DMARC reports," because the receiver never sees the From: header. Here's how that plays out for a client:

• Forwarded mail. A message forwarded by an alias or alumni address arrives from the forwarder's IP, so SPF fails. DKIM usually survives forwarding, so DMARC would pass, but a receiver that rejects on -all early never gets that far.
• Blind spots. Those rejections don't show up in the DMARC reports you rely on to find broken senders.

With ~all, receivers aren't asked to reject on SPF alone, so DKIM and DMARC get to decide.

What Microsoft and Google recommend

• Microsoft recommends -all for Microsoft 365 domains, as part of setting up DKIM and DMARC too. Microsoft notes that DMARC treats both as SPF failures, and that for ~all failures without a DKIM signature, the DMARC policy is effectively ignored in its service. It recommends -all so DMARC can act on messages that fail SPF and lack DKIM.
• Google says ~all tells receiving servers to mark unlisted messages as spam, and "Google recommends you use ~all in your SPF record."

Both are reasonable inside their own platform's logic, and they meet in the middle once DKIM is aligned. The worst options are +all, which authorizes every server on the internet, and ?all (neutral), which says nothing.

Spotting each result in a header

In the Authentication-Results header (RFC 8601), the result appears as spf=softfail or spf=fail, followed by smtp.mailfrom=, which names the envelope domain that was checked. Check that domain first. A softfail for a vendor's bounce domain says nothing about the client's own record. If it's the client's domain, find the sending IP in the Received headers and work out which service sent the message before you add anything to the record.

Choosing for a client

Whichever you choose, the control that actually stops spoofing of the visible From: address is DMARC at enforcement with aligned DKIM, not the SPF ending.

Check the client's SPF ending now

Run the free SPF checker →

It shows the record's all qualifier, flags +all and ?all, walks the include tree, and counts lookups against the RFC 7208 limit of 10.

Founding Partner: $1,999, one time. See every client's SPF ending, DKIM, and DMARC policy side by side, and show them where they stand. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →