SPF glossary
SPF -all vs ~all: hardfail vs softfail explained
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
-all (hardfail) tells receivers that any server not listed in your SPF record is not authorized — fail it. ~all (softfail) says it's probably not authorized — accept the mail but mark it. -all is the strict end-state; ~all is the common rollout stance while you're still confirming senders.
-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 — fail it. ~all says: probably not mine — 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 matters less than people think: DMARC asks whether SPF *passed* with an aligned domain, and both -all and ~all produce the same “not pass” for unlisted senders. Still, -all is the end-state to aim for once your sources are complete — it's the honest statement of your policy — while ~all is a reasonable stance mid-rollout, when your DMARC reports may still be surfacing senders you'd forgotten.
Correct record vs common mistake
Correct
v=spf1 include:_spf.google.com ip4:192.0.2.0/24 -allStrict fail once your sender list is complete — anything not listed is declared not yours.
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 switching ~all to -all | A sender you hadn't discovered yet — softfail was hiding it | Step back to ~all, find the source in your DMARC reports, authorize it, then re-tighten |
| 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, ~all is where rollouts quietly park forever — the audit says “SPF configured” while half your tenants advertise a policy that asks nothing of receivers. 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
“Palisade streamlined all of our DMARC operations. It was so complicated at first, it was taking so much time. It allowed us to get everything done faster and have a complete overview of our operations, at such an affordable cost. We're saving so much time. It's a great improvement for our operations.”
DMARC software that does the work
Once DMARC enforces, alignment is what protects the domain — not the qualifier alone. Palisade reads each client domain's reports, aligns every legitimate sender, and advances the policy to `p=reject` on evidence, so the move to a strict `-all` happens when the data says it's safe, not on a hunch.
1 domain free up to 1,000 emails/month
Questions readers ask