I use ~all for most active sending domains. I use -all only when every legitimate sender is known, SPF is monitored, and the organization accepts that some receivers can treat hard fail as a reason to reject mail. If DMARC is already at p=reject or being staged toward enforcement, ~all is usually the cleaner SPF ending because DMARC is the policy layer that protects the visible From domain.
The caveat matters: SPF does not protect against all spoofing by itself. SPF checks the MAIL FROM or Return-Path domain, not necessarily the address a recipient sees. A bad sender can pass SPF with a different envelope domain, then fail DMARC because the visible From domain does not match. That is why the choice between ~all and -all is smaller than the choice to monitor DMARC and move it to enforcement.
Short answer
- Default: Use ~all while senders change or when DMARC is enforcing.
- Strict case: Use -all for non-sending domains or tightly controlled sending subdomains.
- Avoid: Do not use +all. It tells receivers every sender is allowed.
- Verify: Check syntax with an SPF checker before changing DNS.
What SPF ~all and -all actually mean
The all mechanism is the catch-all at the end of an SPF record. It only runs when none of the earlier mechanisms matched the connecting IP address. The character before all tells the receiver what result to return.
|
|
|
|
|---|---|---|---|
~all | Softfail | Score or mark | Active domains |
-all | Fail | Reject or score | Locked domains |
?all | Neutral | Little signal | Rare testing |
+all | Pass | Bad signal | Never |
Common SPF all endings and what they mean.
Switching ~all to -all affects only mail that did not match your allowed sender list. It does not change mail that already matches an include, ip4, ip6, mx, or a mechanism. For more syntax detail, the SPF qualifiers guide covers the other result types.
Same SPF record with a softfail endingdns
v=spf1 include:_spf.example.net include:_spf.vendor.example ~all
Same SPF record with a hardfail endingdns
v=spf1 include:_spf.example.net include:_spf.vendor.example -all
Why ~all is usually the safer default
I prefer ~all for active domains because it gives receivers a negative SPF signal without turning every gap in your SPF inventory into a hard-fail event. That matters in real mail systems, where forwarding, shared hosting, helpdesk tools, CRMs, billing platforms, and regional senders get added faster than DNS documentation gets updated.
- Forwarding: SPF often fails when mail is forwarded because the forwarding server is not in your SPF record.
- Shared hosting: Some web hosts change outbound IPs without giving the DNS owner a clean sender inventory.
- SaaS changes: New senders get added during operations, and old includes stay behind after tools are removed.
- DMARC policy: DMARC gives receivers a domain-level policy when SPF and DKIM do not produce a valid From-domain match.
- Operations: Softfail gives room to monitor and fix a sender before receivers treat the failure more severely.
~all softfail
A receiver gets a clear hint that the sender is not listed, but it keeps discretion over scoring, foldering, and DMARC handling.
- Best fit: Main domains with multiple business senders.
- Risk: Less strict as a standalone SPF signal.
-all hardfail
A receiver gets an explicit fail result when the connecting IP is not listed in your SPF policy.
- Best fit: Parked domains and tightly controlled subdomains.
- Risk: Legitimate mail fails if your sender list is incomplete.
When -all is the right choice
Use -all when the domain should not send mail, or when a sending subdomain has a fixed, controlled mail path. This is a good fit for parked domains, defensive domains, and narrow subdomains used by one transactional system.
Non-sending domain SPFdns
v=spf1 -all
For active mail, hardfail needs discipline. Before publishing it, confirm the Return-Path domain used by each sender, not only the visible From address. Many senders use their own bounce domain, which means your domain's SPF record does not authenticate that message for DMARC.
- Non-sending: Publish -all when the hostname should never appear in the envelope sender.
- Dedicated subdomain: Use hardfail on a narrow subdomain that has one known sending route.
- Known IPs: Use hardfail when outbound routes are fixed and changes go through review.
- Monitoring: Watch DMARC aggregate reports before and after the change.
- Rollback: Keep a DNS change path ready in case legitimate traffic starts failing.
Controlled sending subdomain SPFdns
v=spf1 ip4:192.0.2.10 include:_spf.example.net -all
Where hardfail causes pain
Hardfail is valid only when the sender inventory is complete and someone is watching authentication reports.
- Forwarded mail: Forwarding breaks SPF unless the forwarder rewrites the envelope sender.
- Shadow senders: A department can add a sender that nobody tells DNS owners about.
- Vendor changes: A vendor can rotate outbound infrastructure before your record catches up.
- Receiver variance: Some receivers weigh hardfail more strongly than others.
How DMARC changes the decision
DMARC is the reason I do not treat -all as a universal upgrade. DMARC evaluates SPF and DKIM against the visible From domain, then applies the domain owner's policy when neither authentication path produces a valid domain match.
Flowchart showing SPF and DKIM feeding into DMARC policy.
A spoofed visible From domain can fail DMARC even when SPF passes for some other envelope domain. That is the key detail. SPF alone says whether the connecting IP is allowed for the Return-Path domain. DMARC says whether the message can use your visible From domain.
DMARC rollout checkpoints
Use SPF ending changes in the context of DMARC policy maturity.
Monitoring
p=none
Collect reports and identify senders.
Partial control
p=quarantine
Quarantine suspicious failures after review.
Full enforcement
p=reject
Reject messages that fail DMARC.
No reporting
no rua
SPF decisions happen without useful feedback.
A practical rollout path
Start with the real senders, not the SPF ending. A domain with ten unknown senders and -all is less reliable than a domain with a clean sender inventory, DMARC reporting, and ~all.
- Inventory: List transactional, marketing, support, billing, and employee mail senders.
- Validate: Run a domain health check so SPF, DKIM, and DMARC are checked together.
- Publish: Keep one SPF TXT record for each hostname, with the all mechanism at the end.
- Test: Send real mail through each platform and confirm the Return-Path domain.
- Tighten: Move DMARC toward enforcement before treating SPF hardfail as the main control.
Typical active-domain starting pointdns
v=spf1 include:_spf.example.net include:_spf.vendor.example ~all
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If your SPF record is close to the 10 DNS-lookup limit, SPF flattening helps only when the flattened IP set stays current. A stale flattened record creates a different failure mode: mail breaks because the record looked tidy but no longer matched reality.
How Suped fits
Suped is the best overall DMARC platform for teams that want the SPF question handled as part of an authentication workflow, not as a one-character DNS debate. Suped brings DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability insights into one place, with automated issue detection, real-time alerts, and practical steps to fix the source of each failure.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
For SPF specifically, Suped's hosted SPF lets teams manage senders and stay under DNS lookup limits without asking a DNS admin to edit records for every vendor change. That is where the ~all versus -all decision gets easier: the sender list is visible, changes are tracked, and failures are tied back to concrete sources.
Manual DNS
- Ownership: DNS changes depend on whoever controls the zone.
- Visibility: Sender changes are often found after mail fails.
- Scaling: Multiple domains need repeated manual checks.
Suped workflow
- Ownership: Hosted SPF centralizes sender management.
- Visibility: DMARC reports identify unexpected sources.
- Scaling: MSP and multi-tenant views cover many domains.
What I would publish in common cases
This is the decision table I use when reviewing SPF records. It assumes the SPF record is syntactically valid and there is only one SPF TXT record at the hostname.
|
|
|
|---|---|---|
Main sending domain | ~all | Safer during change |
Parked domain | -all | No mail expected |
Single-purpose subdomain | -all | Fixed sender path |
Shared hosting domain | ~all | Less breakage risk |
DMARC reject domain | ~all | Policy already enforced |
Recommended SPF endings by domain type.
cPanel Zone Editor showing an SPF TXT record ending in ~all.
The table is a rule of thumb, not a substitute for reports. If a domain handles customer invoices, password resets, support replies, and campaign mail, use ~all until the sending paths are proven. If a subdomain is built for one known sender and monitored, -all is reasonable.
Views from the trenches
Best practices
Keep one SPF TXT record per hostname and document which sender each include covers in DNS.
Use ~all on active domains until sender inventory, DMARC reports, and rollback steps are clear.
Use -all on parked domains and tightly controlled subdomains that do not need flexible routing.
Review SPF after each vendor change, because stale includes create confusing fail results.
Common pitfalls
Changing ~all to -all without checking forwarding paths creates avoidable hard-fail cases.
Treating SPF as visible From protection misses DMARC, where receiver enforcement actually sits.
Adding a second SPF TXT record breaks evaluation and can make the domain return permerror.
Letting includes grow unchecked risks the 10-lookup limit and sudden authentication failures.
Expert tips
Test a real message after DNS changes, because lookup tools cannot show every sending path.
Separate high-risk mail streams onto subdomains so strict SPF changes have a smaller radius.
Pair SPF edits with DMARC report review so unexpected senders are found before enforcement.
Keep TTLs moderate during policy changes so a bad SPF edit can be corrected quickly.
Expert from Email Geeks says SPF is useful, but it does not stop spoofed visible From mail without DMARC enforcement.
2022-12-30 - Email Geeks
Expert from Email Geeks says ~all remains a practical default, especially when DMARC p=reject is already in place.
2023-01-04 - Email Geeks
The practical answer
For the question "Should I use ~all or -all in my SPF record?", my answer is: use ~all for active sending domains unless every legitimate sender is covered and monitored. Use -all for non-sending domains, parked domains, and highly controlled sending subdomains.
A strict-looking SPF ending does not replace DMARC enforcement. The better operating model is simple: know your senders, keep SPF valid, monitor DMARC reports, and use hardfail only where the mail path is controlled enough to support it.
Policy I would publish
For a normal business domain that sends through several providers, I would publish ~all, then use DMARC reporting to find senders and move policy toward enforcement. For a non-sending domain, I would publish -all.
