# SPF softfail vs hardfail: should you use ~all or -all?

URL: https://iblockspam.com/blog/spf-softfail-vs-hardfail
Last updated: 2026-10-09
Published: 2026-10-09
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> What ~all, -all and ?all mean in SPF, what receivers really do with each, how DMARC changes the choice, and which one to use for sending and parked domains.

## Short answer

-all (hardfail) says unlisted servers are not authorized; ~all (softfail) says they probably aren't; ?all (neutral) asserts nothing. With DKIM and DMARC in place, ~all and -all both count as an SPF failure for DMARC. M3AAWG recommends ~all for domains that send mail and -all for domains that never send. Avoid ?all and +all.

Every SPF record ends with an `all` mechanism, and the character in front of it is one of the most argued-over details in email authentication. The answer used to matter a lot. With DKIM and DMARC in place it matters much less, but there are still a few cases where the choice changes what happens to your mail.

## What do ~all, -all, ?all and +all mean?

The character before a mechanism is its **qualifier**. [RFC 7208, section 4.6.2](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.2) defines four, and if you leave it out the default is `+`. The `all` mechanism always matches, so it sets the result for any server not listed earlier in the record.

| Ending | Qualifier | Result for unlisted servers | RFC 7208 meaning |
|---|---|---|---|
| `-all` | `-` | fail (hardfail) | "an explicit statement that the client is not authorized" |
| `~all` | `~` | softfail | "a weak statement by the publishing ADMD that the host is probably not authorized" |
| `?all` | `?` | neutral | the domain "is not asserting whether the IP address is authorized" |
| `+all` or `all` | `+` | pass | Every server on the internet is authorized |

The quotes are from [section 2.6](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.6). `+all` is never correct; it lets anyone send as your domain. If you need a refresher on the rest of the record, see [SPF record syntax and examples](https://iblockspam.com/blog/spf-record-syntax-examples).

## What do receivers actually do with each result?

RFC 7208 deliberately leaves the decision to the receiver. It says there is "no comprehensive normative requirement for message handling in response to any particular result". It does give guidance:

- **Fail** ([section 8.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-8.4)): if a receiver rejects during the SMTP session, it should use reply code 550. Otherwise it should record the result in a header. What happens next "is a matter of local policy".
- **Softfail** ([section 8.5](https://www.rfc-editor.org/rfc/rfc7208.html#section-8.5)): receivers "SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal".
- **Neutral** ([section 8.2](https://www.rfc-editor.org/rfc/rfc7208.html#section-8.2)): "MUST be treated exactly like the 'none' result", the same as having no SPF at all.

Big mailbox providers describe the difference loosely. Google's [About SPF records](https://knowledge.workspace.google.com/admin/security/about-spf-records) page says that with `~all`, receivers "typically accept messages from senders that aren't in your SPF record, but mark them as suspicious", and with `-all` they "may reject" them.

In practice, most large receivers combine SPF with DKIM, DMARC and reputation rather than rejecting on SPF alone. Microsoft 365, for example, has an Advanced Spam Filter setting called **SPF record: hard fail** that marks hardfailing messages as high confidence spam, but [Microsoft Learn](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-policies-asf-settings-about) lists it as off by default. Smaller or self-run mail servers vary. Some reject on any `-all` failure.

## How does DMARC change the picture?

DMARC only cares whether SPF **passed** for a domain that aligns with the From address. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) uses the SPF identity "if there is an SPF 'pass' result". Fail, softfail, neutral and none all mean the same thing to DMARC: SPF didn't help, so DKIM has to. [Microsoft's SPF guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) puts it directly: "DMARC treats `-all` (hard fail) and `~all` (soft fail) as SPF failures."

So once you publish DMARC with an enforcing policy, your DMARC policy decides what happens to spoofed mail, not the SPF qualifier.

### The one place -all can hurt you

There's a catch. Some receivers check SPF early in the SMTP session, before they ever look at DKIM or DMARC. [RFC 9989, section 7.1](https://www.rfc-editor.org/rfc/rfc9989.html) warns that a hardfail "could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place". A message that would have passed DMARC through aligned DKIM is rejected anyway. And because it was rejected early, it "will never appear in aggregate DMARC reports", so you won't see it happen.

The usual trigger is forwarding. When a message is forwarded, it arrives from the forwarder's server, which isn't in your SPF record. RFC 9989 section 7.4 says such mail "will most likely fail SPF checks" while "DKIM signatures will generally remain valid".

[M3AAWG's email authentication best practices](https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf) address this from both sides. For receivers, an SPF fail "should not result in a message rejection until after DMARC has been evaluated and been found to not pass". The only exception is a record of exactly `v=spf1 -all`, which says the domain sends no mail at all. Not every receiver follows that advice.

## Why do Microsoft, Google and M3AAWG disagree?

They're optimizing for different risks.

| Source | Recommendation for sending domains | Reasoning |
|---|---|---|
| [M3AAWG](https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf) | "SPF records should end in ~all" | Avoids early rejection of mail that DMARC would pass |
| [Google](https://knowledge.workspace.google.com/admin/security/set-up-spf) | "Google recommends you use ~all in your SPF record" | Explains that "the ~all tag tells receiving servers to mark messages as spam if they're from servers that aren't listed in the SPF record" |
| [Microsoft](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) | "we recommend `-all` (hard fail)" | Says DMARC policy is effectively ignored for `~all` failures on messages without DKIM signatures |

All three agree on the bigger points: list every legitimate sender, set up DKIM and publish DMARC. For domains that don't send, Microsoft and M3AAWG recommend `v=spf1 -all`, while a tip on Google's [About SPF records](https://knowledge.workspace.google.com/admin/security/about-spf-records) page suggests `~all`.

How do large sites choose? In our [scan of the Tranco top 1,000 domains](https://iblockspam.com/research/email-security-top-1000) in October 2026, 764 published SPF. Of those, 438 (57.3%) ended in `-all`, 274 (35.9%) in `~all`, 19 (2.5%) in `?all`, and 33 (4.3%) delegated the decision with `redirect`. None used `+all`.

## Which one should you use?

1. **Domains that never send mail:** `v=spf1 -all`, plus a DMARC record of `p=reject`. Microsoft and M3AAWG both recommend this for parked domains.
2. **Domains that send mail, while you're still finding all your senders:** `~all`. A missed service gets marked rather than rejected, and your DMARC reports show you what you missed.
3. **Domains that send mail, with DKIM on every service and DMARC enforcing:** either `~all` or `-all` is defensible. `~all` follows M3AAWG and Google and avoids early rejection of forwarded mail. `-all` follows Microsoft and gives receivers that act on SPF alone a stronger signal. Don't switch to `-all` until reports show every legitimate source passing.
4. **Never** use `+all`, and don't leave `?all` in production. Microsoft calls `?all` a testing value.

Changing the qualifier doesn't fix a broken record. If your SPF returns PermError, for example because of [too many DNS lookups](https://iblockspam.com/blog/spf-too-many-dns-lookups), the `all` mechanism is never reached.

## How to check what your domain uses

1. Look up your record with the [SPF Checker](https://iblockspam.com/tools/spf-checker). It shows the `all` qualifier and flags `+all` and `?all`.
2. Send a test message to an outside mailbox and open the headers in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer). Look for `spf=pass` and `dkim=pass` in Authentication-Results.
3. Read a week of [DMARC aggregate reports](https://iblockspam.com/blog/how-to-read-dmarc-reports) and confirm every legitimate source passes DMARC through aligned DKIM, not just SPF.
4. If you need to rebuild the record, the [SPF Generator](https://iblockspam.com/tools/spf-generator) produces a clean one with the ending you choose.

## Next steps

- Check which ending your mail providers document: [SPF records by email provider](https://iblockspam.com/spf) lists each provider's exact record.
- Publish `v=spf1 -all` and `p=reject` on every domain you own but don't send from.
- On sending domains, make sure aligned DKIM is in place everywhere before you worry about the qualifier. [Setting up DKIM in Microsoft 365 and Google Workspace](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace) covers the two most common platforms.
- Keep an eye on changes. iBlockSpam's [domain monitoring](https://iblockspam.com/features/domain-monitoring) alerts you when your SPF or DMARC record changes: weekly on Protect, daily on Protect Plus.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Is ~all or -all better for deliverability?

For mail you actually send, neither should matter, because your real servers pass SPF. The difference only applies to mail from servers not in your record. If your record misses a real sender, -all turns that mistake into a hard failure, which is why ~all (the qualifier Google recommends) is the more forgiving choice while you finish your sender inventory.

### Does DMARC treat softfail and hardfail differently?

No. DMARC uses only an SPF pass for an aligned domain. A softfail, a fail, a neutral and no record all mean SPF didn't provide an aligned pass, so DMARC relies on DKIM. Microsoft's documentation agrees that DMARC treats both -all and ~all as SPF failures, though it adds that DMARC policy is effectively ignored for ~all failures on mail without DKIM.

### Will -all make receivers reject my forwarded mail?

It can. Forwarding usually breaks SPF, and RFC 9989 warns that a hardfail can get a message rejected early in the SMTP session, before DMARC is evaluated, even if aligned DKIM would have passed it. M3AAWG asks receivers not to do this, but not all of them follow that advice.

### What SPF record should a domain that never sends email have?

Use v=spf1 -all. It authorizes nobody, and both M3AAWG and Microsoft recommend it for parked or non-sending domains. Pair it with a DMARC record of p=reject. M3AAWG specifically allows receivers to act on an SPF failure immediately when the record is exactly v=spf1 -all.

### What does ?all mean in SPF?

?all returns neutral for unlisted servers, which means the domain makes no assertion about them. RFC 7208 says a neutral result must be treated exactly like no SPF record at all. Microsoft says it's used for testing and doesn't recommend it in production.

## Sources

- [RFC 7208: Sender Policy Framework (SPF), sections 2.6, 4.6.2 and 8](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 9989: DMARC, section 7.1 (Issues Specific to SPF)](https://www.rfc-editor.org/rfc/rfc9989.html)
- [M3AAWG Email Authentication Recommended Best Practices (September 2020)](https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf)
- [Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)
- [Microsoft Learn: ASF settings in anti-spam policies](https://learn.microsoft.com/en-us/defender-office-365/anti-spam-policies-asf-settings-about)
- [Google Workspace Admin Help: Set up SPF](https://knowledge.workspace.google.com/admin/security/set-up-spf)
- [Google Workspace Admin Help: About SPF records](https://knowledge.workspace.google.com/admin/security/about-spf-records)

## Free tools for this guide

- [SPF Record Generator](https://iblockspam.com/tools/spf-generator): Build a valid SPF record from your mail providers, with a DNS lookup count.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.

---

Source: iBlockSpam, https://iblockspam.com/blog/spf-softfail-vs-hardfail (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt