# SPF ~all vs -all: softfail or hard fail, and which to use

Every SPF record ends with an `all` rule that says what to do with mail from
a server you didn't list:

```
v=spf1 include:_spf.google.com ~all
v=spf1 include:_spf.google.com -all
```

The one character before `all` is the qualifier. It doesn't change which
servers pass; it changes how strongly you tell receivers that everything
else is not you.

## The four qualifiers

| Rule | Result | What RFC 7208 says it means |
|---|---|---|
| `-all` | fail | "an explicit statement that the client is not authorized" |
| `~all` | softfail | "a weak statement" that the host "is probably not authorized" |
| `?all` | neutral | no statement either way; treated exactly like having no SPF |
| `+all` | pass | every server on the internet may send as you |

`+all` makes SPF useless and lets anyone pass. `?all` is for testing only.
The real choice is between `~all` and `-all`.

## What receivers do with each

The RFC leaves the decision to the receiver. For a **fail**, a receiver may
reject the message during the SMTP conversation (with a `550 5.7.1`). For a
**softfail**, it "SHOULD NOT reject the message based solely on this
result", but may look at it more closely, which in practice often means the
spam folder.

## DMARC changed the question

With DMARC published, receivers judge a message by DMARC, and both `~all`
and `-all` count as an SPF failure. A message that fails SPF but carries a
valid DKIM signature for your domain still passes DMARC either way.

The catch with `-all`: some receivers check SPF before DMARC and reject on
a hard fail straight away. The DMARC standard (RFC 9989, and RFC 7489
before it) warns that this can reject mail that DKIM would have saved, and
that such rejections "will never appear in aggregate DMARC reports". That
matters most for mail that is forwarded or sent through a mailing list,
where SPF breaks but DKIM survives.

## Google says ~all, Microsoft says -all

The two largest mailbox providers give opposite advice:

- **Google** recommends `~all` for Google Workspace domains.
- **Microsoft** recommends `-all`, "because we also recommend DKIM and
  DMARC for the domain". It also notes that if a message fails SPF with
  `~all` and has no DKIM signature, the DMARC policy is effectively ignored.

Both are right about their own concern: Google is protecting forwarded mail
from early rejection; Microsoft is making sure a softfail can't slip past
DMARC.

## Which to use

- **You have DKIM on every sending service and DMARC at quarantine or
  reject:** either works, and DMARC is doing the real job. `~all` is the
  safer choice for forwarded mail; `-all` is fine if you prefer the
  stronger statement.
- **You don't have DKIM everywhere yet:** fix that first. Until then, a
  sender you forgot about plus `-all` means bounces, and `~all` means spoofed
  mail can still get through.
- **A domain that never sends email:** publish `v=spf1 -all`, plus a DMARC
  record with `p=reject`. Nothing legitimate can be hurt.

Whichever you choose, the qualifier matters much less than the rest of the
record: listing every service that sends for you and staying within the
[10-lookup limit](/guides/spf-too-many-dns-lookups). Then move DMARC to
enforcement with [DMARC from none to reject](/guides/dmarc-none-to-reject).

## Check your domain

The [SPF lookup counter](/tools/spf-lookup-counter) shows your record, its
`all` rule and how many lookups it uses. The [free scan](/#scan) checks SPF
and DMARC together, and the lookalike domains that could send as you.

## Sources

- [RFC 7208: SPF (2.6 results, 4.6.2 qualifiers, 8.4 fail, 8.5 softfail)](https://www.rfc-editor.org/rfc/rfc7208)
- [RFC 9989: DMARC (7.1)](https://www.rfc-editor.org/rfc/rfc9989)
- [RFC 7489: DMARC (10.1), obsoleted by RFC 9989](https://www.rfc-editor.org/rfc/rfc7489)
- [Google Workspace: Set up SPF](https://knowledge.workspace.google.com/admin/security/set-up-spf)
- [Microsoft: Set up SPF to identify valid email sources](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)

---
Source: https://nameward.app/guides/spf-softfail-vs-fail (updated 2026-10-31)