SPF glossary
SPF -all vs ~all: what each qualifier means
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed September 9, 2026
-all (hardfail) says a server not listed in your SPF record is not authorized. ~all (softfail) says it is probably not authorized, so accept the mail but mark it. ?all (neutral) asserts nothing, and +all (pass) authorizes every server on the internet. Use ~all on a domain that sends mail, -all on one that sends none.
-all vs ~all at a glance | |
|---|---|
| Tag | all (catch-all mechanism) with a qualifier prefix |
| Valid values | -all (fail) · ~all (softfail) · ?all (neutral) · +all (pass, never use) |
| Default | A mechanism with no qualifier defaults to + (pass). A record with no all and no redirect returns neutral for unlisted senders. |
| Where it goes | Always the last term: anything after all is never evaluated. |
How -all vs ~all works
Every SPF mechanism can carry one of four qualifiers that set the result when it matches: + (pass: the default when nothing is written), - (fail, often called hardfail), ~ (softfail), and ? (neutral). In practice you only ever see them on all, the catch-all mechanism that matches every sender the earlier terms didn't, and therefore always ends the record.
-all says: anything not listed above is not mine, so fail it. ~all says: probably not mine, so accept it but mark it (most receivers feed softfail into spam scoring). ?all asserts nothing at all, which makes it pointless in practice. And +all authorizes the entire internet to send as your domain. It must never be used.
With DMARC in place, the qualifier decides less than people think. RFC 9989 evaluates SPF as a pass or a non-pass plus alignment and draws no distinction between softfail and fail, so -all and ~all reach DMARC identically. The difference lands earlier: RFC 7208 section 8.5 says a receiver SHOULD NOT reject on a softfail alone, and section 8.4 places no such limit on a fail, which can be rejected during the SMTP transaction before DMARC evaluation runs. Hence ~all on a domain that sends mail and -all on one that sends none, with hard fail versus soft fail weighing that choice by what the domain does.
Correct record vs common mistake
Correct
v=spf1 include:_spf.google.com ip4:192.0.2.0/24 ~allA domain that sends mail: every source listed, softfail last. A domain that sends none publishes the bare record v=spf1 -all instead, which authorizes no SMTP client at all.
Common mistake
v=spf1 include:_spf.google.com +all+all authorizes every server on the internet to send as this domain. The record passes everything, worse than having no SPF at all.
Generate your SPF record
Build a correct SPF record for your domain. Add your senders, copy the TXT record. Free, no signup.
Who sends email for this domain?
Each service adds its documented include mechanism.
From your provider’s docs, e.g. spf.example-esp.com: commas or spaces between multiple. Some services (Klaviyo, HubSpot, Mailchimp Transactional) authenticate through their own CNAME records instead of a shared include, check their DNS settings page.
How should receivers treat everyone else?
Your SPF record
0/10 lookupsPublish as a TXT record at the domain root. One SPF record per domain: if one exists, merge into it instead of adding another.
yourdomain.com (or @)v=spf1 ~allClick the record to select all of it.
Record type: TXT · ip4/ip6 mechanisms don’t count against the 10-lookup limit.
After you publish
- Add the TXT record at your DNS host.
- Verify it with the free SPF checker.
- SPF alone doesn’t stop spoofing, pair it with DKIM and a DMARC policy. Generate one with the DMARC record generator.
Troubleshooting -all vs ~all
| Issue | Likely cause | Fix |
|---|---|---|
| Legitimate mail failing after a switch from ~all to -all | A sending service the record never listed. Softfail was marking that mail; hardfail gets it rejected | Return to ~all, find the source in your DMARC reports, and authorize it there |
| Spoofed mail still delivered despite -all | SPF alone doesn't police the visible From header, receivers weigh it as one signal | Pair SPF with DKIM and a DMARC policy at quarantine or reject; that's what actually instructs receivers |
| Record ends in +all or ?all after a support 'fix' | Someone loosened the record to make a delivery problem go away | Remove it and fix the real cause, authorize the failing sender properly instead of authorizing the whole internet |
Why it matters for MSPs
Across a managed fleet the qualifier is not where the risk sits. ~all is the right ending for a tenant that sends mail, but it only protects the domain once DMARC moves past p=none, and p=none is where rollouts quietly park forever: the audit says “SPF configured” while nothing is enforcing anything. Worse is the one domain where a client's web developer “fixed” a delivery problem with +all: that tenant is now a spoofing free-for-all, and nothing in a green DNS checkmark will tell you.
Trusted by MSPs
“All our emails started magically reaching the inbox in less than a week”
Marc-André Campagna , CEO, gaiiaRead the case study →5.0 out of 5 on G2Trusted by over 10,000 domains
More customer stories →
DMARC software that does the work
Once DMARC enforces, alignment is what protects the domain, not the qualifier alone. The control that tightens over time is the DMARC policy, not the SPF qualifier. Palisade reads each client domain's reports, aligns every legitimate sender, and proposes each step to p=reject on evidence, for your team to approve.
15-day full-product trial. Nothing is charged until it ends.
Questions readers ask