Should I use ~all or -all in my SPF record?
Published 29 Jun 2025
Updated 24 Oct 2026
12 min read
Summarize with
Updated on 24 Oct 2026: We clarified SPF include and redirect behavior, corrected hosted SPF setup advice, and added checks for delivery failures missing from DMARC reports.
Use ~all for most active sending domains. Use -all only after confirming every legitimate sender and monitoring SPF. The organization also needs to accept that a receiver can reject hardfail under its local policy. If DMARC already uses p=reject or is moving toward enforcement, ~all is usually the cleaner SPF ending because DMARC applies policy to the visible From domain.
The caveat matters: Sender Policy Framework (SPF) does not protect against all spoofing by itself. SPF checks the MAIL FROM or Return-Path domain, or the HELO identity when the reverse path is null. It does not necessarily check 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. SPF evaluates mechanisms left to right, stopping at the first match or an evaluation error. The tilde (~) is the softfail (soft fail) qualifier; the hyphen (-) is the fail qualifier, commonly called hardfail (hard fail).
|
|
|
|
|---|---|---|---|
~all | Softfail | Should not reject solely on softfail; filtering still applies | Active domains |
-all | Fail (hardfail) | Local policy; possible SMTP rejection | Controlled domains |
?all | Neutral | Same handling as no SPF result | Temporary testing |
+all | Pass | Pass for every sender that reaches this mechanism | Never |
Common SPF all endings and what they mean.
A bare all means +all because the pass qualifier is implied. Leaving all out leaves unmatched senders with a neutral result only when no redirect= applies. Without redirection, ?all and an omitted all are usually too weak for production domains, while +all is unsafe because every unmatched sender can receive SPF pass.
Switching ~all to -all affects only mail whose SPF evaluation reaches that final mechanism. It does not change a pass already returned by an include, ip4, ip6, mx, or a mechanism.
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
How include and redirect affect ~all and -all
An include does not copy another record's ending into yours. If an included policy returns fail or softfail, that include does not match, and SPF continues with your next mechanism. An included -all therefore does not override your ~all. Evaluation errors propagate instead.
When no mechanism matches, redirect= delegates the whole SPF result, including the ending, to another record. Do not append ~all or -all to the record below: any all mechanism disables redirect= under RFC 7208.
Redirect-only SPF recorddns
v=spf1 redirect=_spf.example.net
Set your chosen ending in the redirect target's SPF record.
Why ~all is usually the safer default
For active domains, ~all is usually safer 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, billing platforms, and regional senders get added faster than DNS documentation gets updated. M3AAWG's email authentication recommendations also favor ~all for sending domains and v=spf1 -all for domains that never send mail.
- Forwarding: SPF often fails when mail is forwarded unless the forwarder rewrites the envelope sender, such as through Sender Rewriting Scheme (SRS). SRS can produce an SPF pass for the forwarder's domain, which normally does not match the original visible From domain. See RFC 7960.
- 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
Softfail means the sender is probably unauthorized. The receiver should not reject solely on this result, but it still applies filtering and DMARC policy.
- 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 or defensive domains. It also fits 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.
Do not add a web server, agency server, or vendor IP to SPF just because it can send a message with your visible From address. Add it only if that system legitimately sends with your domain in the MAIL FROM identity or the vendor gives a documented SPF include for that exact sending path.
- Non-sending: Publish v=spf1 -all with no authorized senders when the hostname is never used as a MAIL FROM or HELO/EHLO identity.
- 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 and sending-platform delivery logs 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
A complete sender inventory is necessary for hardfail, but forwarding can still cause legitimate delivery failures. Review delivery logs as well as authentication reports.
- Forwarded mail: SPF often fails when the forwarding server's IP is not authorized for the original envelope domain.
- 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: A receiver can reject an SPF fail during SMTP under its local policy.
How DMARC changes the decision
DMARC is the reason -all should not be treated as a universal upgrade. Under RFC 9989, DMARC evaluates whether SPF or DKIM passes with a domain that matches the visible From domain, which the standard calls the Author Domain. When neither authentication path produces a valid domain match, the domain owner's requested policy becomes an input to the receiver's handling decision.
Flowchart showing SPF, DKIM, From-domain matching, and DMARC policy.
A spoofed visible From domain can fail DMARC even when SPF passes for another envelope domain. SPF says whether the connecting IP is allowed for the Return-Path domain. DMARC checks whether a passing SPF or DKIM domain matches the visible From domain. Both softfail and fail are non-pass SPF results for DMARC, so switching between them does not repair a DMARC failure. A passing DKIM signature with a matching domain can still make DMARC pass.
DMARC rollout checkpoints
Use SPF ending changes in the context of DMARC policy maturity.
Monitoring
p=none
Collect reports and identify senders.
Quarantine policy
p=quarantine
Request quarantine handling for DMARC failures.
Reject policy
p=reject
Request rejection for messages that fail DMARC.
No reporting
no rua
SPF decisions happen without useful feedback.
Why hardfail can stop a later DMARC pass
A receiver can evaluate SPF during the SMTP MAIL FROM command, before the message headers and body arrive. RFC 7208 leaves final handling to local policy and permits rejection for an SPF fail. If the receiver rejects at that point, it cannot evaluate the message's DKIM signature or reach a later DMARC pass through a matching DKIM domain.
This is one operational reason ~all often fits active domains. RFC 7208 says receiving software should not reject a message based only on softfail, which gives DKIM and DMARC evaluation a chance to complete. The receiver still controls final delivery under its local policy.
RFC 9989 also explains that messages rejected before SMTP DATA do not appear in DMARC aggregate reports because the receiver has not received the visible From header. Check SMTP rejection details in sending-platform logs too; clean DMARC reports alone cannot prove that -all caused no delivery failures.
How to change your SPF ending safely
Start with an inventory of legitimate senders. Changing ~all to -all does not authorize a missing sender.
- Inventory: List transactional, support, billing, employee, and campaign mail senders.
- Validate: Run a domain health check so SPF, DKIM, and DMARC are checked together.
- Publish: Update the single SPF TXT record at each sending hostname. Put all last unless the policy uses redirect=.
- Test: Send real mail through each platform and a forwarding path. Check Return-Path and the receiving system's Authentication-Results header for the SPF result and checked domain.
- Enforce: Test forwarding and mailing lists before tightening DMARC. For p=reject, RFC 9989 requires valid DKIM signatures; use a signing domain that matches the visible From domain.
- Recheck: Allow DNS caches to expire according to the previous TTL, then verify the published record and test messages again. Keep the prior record for rollback.
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
SPF lives in DNS at the hostname being checked. A firewall, spam filter, or mail gateway setting does not change the SPF record that outside receivers query, although those systems can use SPF results in their own filtering. Subdomains do not inherit SPF from the parent domain. Publish a record for each hostname used in MAIL FROM or HELO/EHLO.
If SPF evaluation exceeds RFC 7208's 10-term DNS-lookup limit, the result is permerror. Count evaluated DNS-querying terms across nested includes and redirects, not just the includes visible in your own record. Neither ~all nor -all fixes this error. SPF flattening helps only when the flattened IP set stays current. A stale flattened record can stop legitimate mail passing SPF.
In a test message, spf=pass means the checked envelope domain authorized the sending IP. spf=softfail or spf=fail needs investigation for legitimate mail, while permerror indicates a policy or evaluation problem and temperror indicates a temporary problem. Use only results added by the receiving system.
Monitor SPF changes with Suped
Suped is our DMARC reporting and email authentication platform. Its DMARC reports show which sources reporting receivers see using the domain, while SPF and DKIM checks help trace failures before an SPF ending changes.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record 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. Review reported SPF failures against known senders before deciding whether -all is appropriate.
For new hosted SPF setups, publish the redirect= value shown in Suped and keep ~all or -all in the hosted policy at the redirect target. Existing include: setups remain supported; their public SPF record still controls the final ending.
Manual DNS
- Ownership: DNS changes depend on whoever controls the zone.
- Visibility: Document each sender and review authentication reports.
- 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 to publish in common cases
Use this decision table 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 | Optional after sender and forwarding tests |
Shared hosting domain | ~all | Less breakage risk |
Active domain with DMARC p=reject | ~all | Avoids rejection solely on SPF before DKIM evaluation |
Recommended SPF endings by domain type.
cPanel Zone Editor showing an SPF TXT record ending in ~all softfail.
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 with a documented sender inventory, DMARC reports, and rollback steps.
Use -all on parked domains and tightly controlled subdomains that do not need flexible routing.
Remove retired SPF includes after vendor changes to limit authorization and unnecessary lookups.
Common pitfalls
Changing ~all to -all without checking forwarding paths creates avoidable hard-fail cases.
Relying on SPF alone for visible From protection misses the domain checks that DMARC adds.
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.
Lower TTL before a planned change and wait out the previous TTL to keep rollback delays short.
Expert view
SPF helps authorize the envelope domain, but visible From protection still depends on DMARC enforcement.
2022-12-30 - Email Geeks
Expert view
~all remains a practical default when DMARC p=reject already protects the visible From domain.
2023-01-04 - Email Geeks
Frequently asked questions
No. -all does not improve mail that already passes SPF or fix policy errors. It gives receivers a stronger unauthorized-sender signal, but legitimate forwarded mail can still fail SPF even when every original sender is listed.
No. SPF checks the Return-Path domain. DMARC is needed to apply policy to the visible From domain that recipients see.
Yes. Publish v=spf1 -all with no authorized sender mechanisms, and pair it with DMARC enforcement. This SPF record applies only to its exact hostname, so review subdomains separately.
No. It is a softfail signal. It is often the right choice for active domains, especially when DMARC reporting and enforcement are in place. Softfail still does not count as an SPF pass for DMARC.
Do not publish both. The first all mechanism always matches, so mechanisms after it are ignored. Use one final all mechanism unless the policy uses redirect=, which requires omitting all. Multiple SPF records at the same hostname cause permerror.
+all means unmatched senders return SPF pass. Do not use it on production domains because it authorizes everyone not already matched earlier in the record.
