Contents
SPF (Sender Policy Framework) records terminate with a default qualifier indicating how receiving servers should treat mail from IPs not explicitly authorised in the record. The two practical choices in 2026 are -all (hard fail) producing explicit "not authorised" verdict and ~all (soft fail) producing "probably not authorised" hedge. Despite intuition suggesting hard fail provides stronger security, soft fail is the recommended default for almost all operators in 2026 because hard fail breaks legitimate forwarding scenarios while DMARC p=reject achieves equivalent security with either qualifier. The advice from security scanners flagging ~all as weak is generally wrong for production sending domains; the correct security upgrade is not ~all to -all but rather ~all plus DKIM plus DMARC p=reject.
This comparison covers the practical SPF qualifier decision in 2026: the RFC 7208 specifications defining both qualifiers, the receiver behaviour differences between hard fail explicit rejection and soft fail spam score increase, the DMARC interaction making both qualifiers achieve equivalent security with p=reject, the legitimate forwarding scenarios where hard fail produces false positives and soft fail tolerates, mailing list and third-party sender implications, the operator decision framework based on DMARC deployment maturity and sending complexity, and the 2026 recommendations from email authentication community.
Two SPF qualifier choices
Same letter "all". Different leading character. Substantially different meaning.
SPF records published in DNS define which IP addresses are authorised to send mail on behalf of a domain. The record terminates with the "all" mechanism qualified by one of four characters indicating policy for unmatched IPs: + (pass, deprecated), - (fail), ~ (softfail), ? (neutral). The hyphen and tilde qualifiers produce the meaningful practical choice; pass and neutral are inappropriate for production sending domains.
Hard fail (-all): definitively states the sending IP is not authorised. RFC 7208 specifies this result means the message should be rejected by receiving servers. The qualifier produces strongest possible rejection signal.
Soft fail (~all): hedges that the sending IP is probably not authorised but does not insist on rejection. RFC 7208 specifies receivers should treat the message as suspicious but typically accept it with spam score adjustment. The qualifier produces signal rather than verdict.
The choice between hard fail and soft fail affects email authentication policy substantially despite the apparent similarity of the qualifiers. The practical implications cascade through receiver behaviour, forwarding tolerance, mailing list compatibility, and DMARC interaction.
The intuition trap: hard fail looks more secure than soft fail to administrators reading SPF documentation for the first time. Stronger statement should equal better security. Security scanners reinforce this intuition by flagging ~all as weak compared to -all. The intuition leads many operators to switch from ~all to -all believing they are strengthening their security posture.
The intuition is wrong in 2026 for most domains. The reasons require understanding how DMARC changes the security equation, how legitimate forwarding works, and how receivers actually evaluate authentication signals. The remainder of this comparison covers these mechanisms in detail.
Hard fail specification
SPF hard fail has specific characteristics defined by RFC 7208.
RFC 7208 specification. The "-" qualifier produces result "fail" indicating the sending host is not authorised to use the identity (typically the MAIL FROM domain or HELO identity). The receiving server should reject the message or take other restrictive action.
Definitive signal. Hard fail represents explicit policy statement that the sending IP is not authorised. Unlike soft fail's hedge, hard fail commits to a verdict.
DMARC interpretation. Hard fail is interpreted as DMARC fail definitively in all DMARC packages. There is no ambiguity in how DMARC packages process hard fail results.
Receiver behaviour. Standards-compliant receivers should reject messages producing hard fail SPF result. Specific implementation varies: some receivers issue 550 SMTP rejection; some defer with 4xx temporary failure; some accept with spam folder routing; some implement combined logic with DMARC and other signals.
Example SPF record with hard fail:
v=spf1 include:_spf.google.com include:sendgrid.net -all
The record authorises Google Workspace and SendGrid IPs for sending; the -all terminator instructs receivers to reject mail from any other IP.
Hard fail strengths.
- Explicit policy statement. Unambiguous declaration of authorised sending IPs.
- Strongest rejection signal. Receivers have clear instruction; no interpretation ambiguity.
- Consistent DMARC interpretation. All DMARC packages interpret hard fail the same way.
- Phishing protection. Unauthorised IPs spoofing the domain face clearer rejection.
Hard fail weaknesses.
- Forwarding breakage. Forwarded mail from legitimate forwarders not in SPF record gets rejected; common scenario for users with email forwarding rules.
- Mailing list incompatibility. Traditional mailing list software forwards messages from list server IPs that are not in original sender's SPF record; hard fail rejects mailing list distributions.
- Third-party service brittleness. Adding new sending services requires SPF record update before sending; hard fail rejects mail from new services until SPF is updated.
- False positive risk. Legitimate mail can be rejected due to SPF lookup edge cases (DNS timeouts, configuration drift, deliberate forwarding).
- SPF lookup limit issues. SPF has 10-DNS-lookup limit; complex records with many includes can exceed limit producing permerror result which may interact with hard fail in problematic ways.
Soft fail specification
SPF soft fail has different characteristics matching its hedge interpretation.
RFC 7208 specification. The "~" qualifier produces result "softfail" indicating the sending host is probably not authorised but the policy is hedged. Receivers should typically accept the message but treat it as suspicious; common implementations increase spam score or apply other graduated responses.
Hedge signal. Soft fail represents intentional hedge: the policy declares specific authorised IPs but acknowledges that mail from other IPs may still be legitimate (forwarded, mailing list distributed, etc.).
DMARC interpretation variance. Soft fail interpretation varies across DMARC packages. OpenDMARC default interprets soft fail as DMARC fail; some configurations allow soft fail to be interpreted as pass. The variance means soft fail behaviour can differ across receiver implementations.
Receiver behaviour. Standards-compliant receivers should accept messages with soft fail but treat as suspicious. Specific implementation varies: most major receivers (Gmail, Yahoo, Microsoft, Apple) accept and route to inbox or spam based on combined signals; some receivers apply spam score increase; some route to spam folder; few reject outright.
Example SPF record with soft fail:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
The record authorises Google Workspace and SendGrid IPs; the ~all terminator instructs receivers to treat mail from other IPs as suspicious but not necessarily reject.
Soft fail strengths.
- Forwarding tolerance. Legitimate forwarded mail (work-to-personal forwarding, vacation forwards, role aliases) typically gets accepted with spam score increase rather than rejected.
- Mailing list compatibility. Traditional mailing list distributions tolerated; mail from list server IPs gets accepted despite not being in original sender's SPF.
- Third-party service flexibility. New sending services can be added without immediate SPF rejection during configuration transition.
- False positive resistance. Edge cases in SPF evaluation do not cause hard rejections; legitimate mail flows continue with spam handling.
- DMARC security retained. When combined with DMARC p=reject, soft fail provides equivalent security to hard fail for spoofing prevention.
Soft fail weaknesses.
- Apparent weakness. Security scanners and uninformed reviewers flag ~all as weaker than -all; the perception affects security audits.
- Variable receiver interpretation. Different receivers handle soft fail differently; less predictable than hard fail's consistent behaviour.
- OpenDMARC default behaviour. OpenDMARC interprets soft fail as DMARC fail by default; some operators may not realise this.
- Less explicit phishing rejection. Phishing attempts spoofing the domain face less explicit SPF rejection (though DMARC catches them).
Receiver behaviour comparison
Receiver behaviour differs between hard fail and soft fail in specific patterns.
| Receiver scenario | Hard fail behaviour | Soft fail behaviour |
|---|---|---|
| Standards-compliant strict | SMTP 550 rejection | Accept with spam score increase |
| Major mailbox provider with DMARC p=reject | Reject (DMARC enforcement) | Reject (DMARC enforcement) |
| Major mailbox provider with DMARC p=none | Increase spam score; possible spam folder | Accept with minor spam score increase |
| Major mailbox provider with no DMARC | Reject or quarantine | Accept with spam score increase |
| Email forwarding service | Reject forwarded mail from non-SPF IP | Accept forwarded mail with score increase |
| Mailing list receiver | Reject mailing list distributions | Accept mailing list distributions |
| Aggressive spam filter | Reject definitively | Quarantine to spam folder |
| Permissive receiver | Accept but flag as failed | Accept normally |
The pattern observation:
With DMARC p=reject deployed: behaviour is essentially identical. DMARC enforcement makes the SPF qualifier choice irrelevant for spoofing protection at major mailbox providers.
Without DMARC or with permissive DMARC: hard fail produces more rejections of both legitimate and illegitimate mail; soft fail produces fewer rejections preserving legitimate forwarding while accepting some spoofing risk.
For forwarded mail: hard fail breaks forwarding scenarios that soft fail tolerates. The forwarding problem is the primary practical reason to prefer soft fail.
DMARC interaction equivalence
DMARC's role in email authentication makes the SPF qualifier choice substantially less important than it would otherwise be.
DMARC mechanism:
- Combines SPF and DKIM. DMARC evaluation considers both SPF and DKIM results plus domain alignment between authenticating domain and From header domain.
- Passes if either SPF or DKIM passes plus aligns. DMARC does not require both SPF and DKIM to pass; either authentication mechanism with alignment satisfies DMARC.
- Policy determines disposition. DMARC policy (p=none, p=quarantine, p=reject) determines what receivers do with messages failing DMARC.
- Reporting collected. DMARC aggregate reports document what receivers see across all sources.
SPF qualifier interaction with DMARC:
| Scenario | SPF hard fail (-all) | SPF soft fail (~all) |
|---|---|---|
| DMARC p=reject + DKIM alignment | Message accepted (DKIM passes) | Message accepted (DKIM passes) |
| DMARC p=reject + SPF alignment | Message accepted (SPF passes for authorised IP) | Message accepted (SPF passes for authorised IP) |
| DMARC p=reject + neither SPF nor DKIM aligns | Reject | Reject |
| DMARC p=quarantine + neither aligns | Quarantine | Quarantine |
| DMARC p=none + neither aligns | Accept; report only | Accept; report only |
| No DMARC + SPF hard fail unauthorised IP | Reject likely | Accept with score increase |
| No DMARC + SPF soft fail unauthorised IP | N/A | Accept with score increase |
The implication: DMARC p=reject deployment makes hard fail vs soft fail choice irrelevant for security purposes. The qualifier matters only for receivers without DMARC enforcement or for domains without DMARC deployed.
Statistical reality: 78% of DMARC passes come via DKIM alignment versus 22% via SPF alignment according to DMARCReport's analysis of 1.2M messages. For forwarded mail the DKIM percentage jumps to 93%. DKIM survives forwarding better than SPF; the authentication landscape increasingly relies on DKIM rather than SPF for legitimate mail flow.
The 2026 reality: SPF alignment matters less than DKIM alignment for most legitimate mail. Hard vs soft fail SPF qualifier matters even less when DMARC properly evaluates both authentication mechanisms.
Automated security scanners frequently flag SPF records ending in ~all as security weaknesses, recommending operators switch to -all. The scanner advice is generally wrong for production sending domains in 2026. The scanners typically apply legacy heuristics from earlier email authentication eras when SPF was the primary anti-spoofing mechanism; with DMARC widely deployed, the threat model has changed substantially. Operators receiving security scan reports flagging ~all as weak should: verify the scanner's specific recommendation context; check whether DMARC is deployed (if yes, the ~all is fine); consider whether the recommended -all would break legitimate forwarding or mailing list scenarios; document the soft fail decision rationale for future security audits; potentially educate the security team on the SPF vs DMARC relationship in modern email authentication. The correct security posture for 2026 is ~all + DKIM + DMARC p=reject with proper alignment; not -all replacing ~all. Operators following scanner recommendations to switch to -all without understanding the DMARC interaction frequently create operational problems (broken forwarding, mailing list rejections) without gaining meaningful security improvement.
Forwarding implications
Email forwarding is the primary practical reason to prefer soft fail over hard fail.
Forwarding scenarios common in 2026:
- Work-to-personal forwarding. Employees forward work email to personal addresses (Gmail, iCloud, etc.); forwarding server is the work mail server, not original sender's SPF.
- Vacation auto-forward. Out-of-office auto-forward sends mail to colleagues or alternative addresses; forwarding occurs through receiver's mail infrastructure.
- Role-based aliases. Aliases like info@example.com forward to actual recipients; forwarding mail server's IP not in original sender's SPF.
- Mail filtering services. Corporate mail security appliances (Mimecast, Proofpoint, Barracuda) process mail through their infrastructure before forwarding to corporate mail; their IPs not in original senders' SPF.
- Personal forwarding rules. Users configure forwarding rules to filter or route mail; forwarding occurs without sender's knowledge.
- Domain consolidation forwarding. Organisations forward mail from old domains to new domains during transitions; the forwarding server's IP not in original SPF.
Hard fail behaviour for forwarded mail:
The forwarding server (not original sender's IP) attempts delivery to ultimate recipient. SPF check at recipient's server uses MAIL FROM domain (which is original sender's domain) but evaluates against forwarding server's IP. The forwarding server's IP is not in original sender's SPF record. Hard fail produces explicit rejection.
Soft fail behaviour for forwarded mail:
Same scenario but soft fail produces "probably not authorised" hedge rather than rejection. Receiving server typically accepts with spam score increase. The legitimate forwarded mail reaches recipient.
SRS (Sender Rewriting Scheme) solution:
SRS is the technical solution for SPF-friendly forwarding. The forwarding server rewrites the MAIL FROM address to use forwarding server's domain rather than original sender's domain. SRS allows hard fail to work correctly across forwarders that implement it. However, SRS adoption is incomplete; many forwarders do not implement SRS, breaking hard fail SPF scenarios. Soft fail tolerates non-SRS forwarders that hard fail rejects.
2026 operator recommendations
Email authentication community recommendations for 2026:
Use ~all (soft fail) for all production sending domains. The recommendation applies to virtually all domains that send legitimate business mail. Soft fail tolerates legitimate forwarding while DMARC provides the strict security enforcement.
Deploy DMARC progressively. The DMARC deployment progression matters more than SPF qualifier choice. Standard progression:
- Start with p=none for 2-4 weeks collecting aggregate reports
- Identify failure sources and address legitimate ones
- Move to p=quarantine with pct=25 for 2 weeks
- Increase to pct=100 quarantine for 2 weeks
- Move to p=reject for ongoing protection
Ensure DKIM alignment. 78% of DMARC passes come via DKIM alignment. DKIM signing with d= domain matching From domain provides robust authentication that survives forwarding.
Use -all only for non-sending domains. Domains that never send mail (parked domains, MX-only domains, subdomain delegation) should use v=spf1 -all to explicitly state no authorised senders.
Combine with subdomain protection. Set DMARC sp=reject on root domain to prevent subdomain spoofing; subdomains without explicit DMARC inherit the strict subdomain policy.
Monitor DMARC aggregate reports. Regular review of aggregate reports identifies authentication problems early; tools like dmarcian, Valimail, or self-hosted parser process the XML reports.
Stay under SPF 10-lookup limit. Complex SPF records with many includes can exceed RFC's 10 DNS lookup limit producing permerror. Use SPF flattening tools (CloudFlare's SPF flattener, EasyDMARC) to reduce lookup count when needed.
Real-world SPF examples
Real-world SPF record examples illustrating qualifier patterns:
Google Workspace plus SendGrid (soft fail):
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Google Workspace plus Mailgun plus self-hosted (soft fail):
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~all
Marketing domain with multiple ESPs (soft fail):
v=spf1 include:_spf.salesforce.com include:_spf.google.com include:_spf.intuit.com ~all
Parked domain (hard fail appropriate):
v=spf1 -all
Subdomain delegated to specific service (soft fail):
v=spf1 include:amazonses.com ~all
Complex enterprise (soft fail, near lookup limit):
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.salesforce.com include:_spf.intuit.com include:sendgrid.net include:mailgun.org ~all
Pattern observations:
Most production domains use ~all. The major email providers (Google, Microsoft, Apple, Yahoo, ProtonMail) themselves use ~all in their SPF records demonstrating the recommended practice.
Hard fail rare in production. Hard fail typically appears only in security-conscious enterprise domains with mature email authentication discipline or parked/non-sending domains.
Include depth matters. Complex SPF records with many includes can exceed 10-lookup limit; pre-flattening or careful management required.
IP literals reduce lookups. Direct IP4/IP6 mechanisms do not count against DNS lookup limit; include mechanisms do.
Decision framework
The decision framework for SPF hard fail vs soft fail in 2026:
Use ~all (soft fail) when: domain sends business or marketing email; users might forward mail to other addresses; mailing lists or distribution mechanisms exist; multiple third-party sending services in use; new sending services may be added periodically; DMARC is deployed providing strict security enforcement; following email authentication community best practices for 2026.
Use -all (hard fail) when: domain never sends any mail (parked domain, MX-only); maximum strictness required in narrow controlled context; combined with mature SRS-enabled forwarding infrastructure; specific security compliance requirements mandate -all; legitimate operational complexity confirmed acceptable.
Combine with DMARC properly when: regardless of SPF qualifier choice, deploy DMARC progressively (p=none → p=quarantine → p=reject); ensure DKIM signing with proper alignment; monitor aggregate reports; address authentication failures identified in reports.
Do not switch from ~all to -all when: security scanner flags ~all without considering DMARC context; legitimate forwarding scenarios exist in your mail flow; mailing lists or third-party services depend on flexible SPF; DMARC is not deployed (deploy DMARC first); uncertain about consequences for legitimate mail.
Do not skip DMARC because of -all when: some operators believe -all replaces need for DMARC; this is incorrect; -all without DMARC provides weaker security than ~all + DMARC + DKIM combination; deploy DMARC regardless of SPF qualifier choice.
The 2026 default progression for typical operators:
- Publish SPF record with ~all qualifier listing all authorised sending IPs and includes
- Configure DKIM signing for all sending streams with proper key rotation
- Deploy DMARC with p=none collecting aggregate reports
- Address authentication failures identified in reports
- Progress DMARC to p=quarantine then p=reject following standard progression
- Monitor ongoing aggregate reports for any new authentication issues
- Maintain ~all SPF policy indefinitely; switch to -all only if compelling reason emerges
An e-commerce client we worked with through 2024 illustrates SPF hard fail breakage in production. They had switched from ~all to -all in their SPF record following a security audit recommendation in late 2023. The audit flagged ~all as security weakness without considering their DMARC deployment. Initial post-switch behaviour appeared normal; no immediate problems visible. Over several weeks, support tickets accumulated: customers reporting they did not receive order confirmations forwarded to their personal email addresses; vendor communications going to spam at recipient organisations; mailing list announcements failing for subscribers using forwarding services. Investigation revealed: hard fail was rejecting forwarded mail at multiple receivers; their DMARC was deployed (p=reject) meaning the hard fail was redundant for security; the rejection messages mostly went to bounce handling without explicit explanation. We reverted to ~all and the forwarding issues resolved within DNS propagation period. Security posture remained equivalent because DMARC p=reject provides actual security enforcement. Operational disruption ceased. The lesson: security scanner recommendations should be evaluated in context of complete authentication stack rather than implemented blindly. The ~all SPF qualifier combined with proper DMARC deployment provides robust security without the operational fragility of -all. Operators receiving security recommendations to switch from ~all to -all should evaluate the trade-off carefully and typically maintain ~all unless specific compelling reason exists.