Understanding SPF Qualifiers: -all vs ~all
Use ~all (softfail) while you are still discovering every service that sends mail for your domain, then switch to -all (hardfail) once your record is complete and your DMARC reports show near-zero unexpected failures. ~all tells receivers "mail from an unlisted server is suspicious but deliver it anyway"; -all tells them "mail from an unlisted server is unauthorized." Neither qualifier should be a permanent resting state — ~all is the rollout mode and -all is the destination. And if you already run DMARC at p=reject, the choice matters far less than most guides claim, because DMARC alignment, not the SPF qualifier, is what actually gets spoofed mail rejected at Gmail and Microsoft 365.
That's the summary an AI Overview will give you. Here's what it can't show you: the two qualifiers do not behave the way the words "fail" and "reject" imply at real inboxes, the safe transition has a specific order, and forwarding quietly breaks -all unless one other thing is in place. The comparison table, the decision diagram, and the live SPF record builder below let you settle your own record instead of reading a generic definition.
-all vs ~all at a Glance
-all (hardfail) | ~all (softfail) | ?all (neutral) | |
|---|---|---|---|
| Meaning | Unlisted senders are unauthorized | Unlisted senders are suspicious | No assertion made |
| Typical receiver action on failure | Strong spam signal; reject when combined with DMARC p=reject | Deliver, usually to spam/flagged | Deliver normally, no penalty |
| Spoofing protection | Highest | Partial (relies on DMARC to enforce) | None |
| Risk of blocking legitimate mail | Higher (forwarding, missed sources) | Low | None |
| Good for | Mature, fully-documented mail infrastructure | Initial rollout and monitoring | Almost never in production |
| When to use | After your record is complete and DMARC reports are clean | While discovering and adding sending sources | Only to deliberately disable SPF enforcement |
The single most misread row is "receiver action." -all on its own rarely triggers an outright rejection at Gmail or Microsoft 365 — those providers treat it as a heavy spam-scoring signal and let DMARC make the reject/quarantine decision. So the practical upgrade from ~all to -all is mostly about tightening the input DMARC evaluates, not about SPF single-handedly bouncing mail.
What SPF Records Do
SPF records specify which mail servers are authorized to send email on behalf of your domain. An SPF record might look like:
v=spf1 include:_spf.google.com include:sendgrid.net -all
This record says "email from this domain can come from Google's mail servers, SendGrid's mail servers, or any server that matches the include rules, and nothing else."
The final qualifier (-all or ~all) determines what happens when an email fails SPF authentication—when it comes from a server not listed in your SPF record.
Build and validate your own record — with a live DNS-lookup counter so you don't blow past the 10-lookup limit — before you decide on the trailing qualifier:
-all: The Hard Fail Qualifier
The -all qualifier (pronounced "dash all") represents a hard fail. When an email fails SPF authentication and you use -all, you are telling receivers the sending server is unauthorized and the message should be treated as a hard failure.
v=spf1 include:_spf.google.com -all
With this configuration, if an email claims to come from your domain but originates from a server not in your SPF record, receivers treat it as unauthorized. In practice, big providers like Gmail and Microsoft 365 rarely bounce it on the SPF fail alone — they apply a strong spam-scoring penalty and hand the enforcement decision to DMARC. Combined with a DMARC policy of p=reject, that unauthorized message is what actually gets rejected. -all is the most aggressive SPF posture and the right input for DMARC enforcement.
The advantage is clear: nobody can spoof your domain by claiming to send from it while using unapproved servers. Phishing emails claiming to come from your domain will be rejected.
However, -all creates risks:
False Positives - Legitimate emails from authorized sources might fail if they're forwarded through additional mail servers not listed in your SPF record. Some legitimate business processes involve forwarding that can break SPF alignment.
Legacy System Compatibility - Older or misconfigured systems might send email through backup mail servers not in your SPF record, causing legitimate emails to bounce.
Third-Party Integrations - Contractors, temporary workers, or integrated services might send emails through their own servers, causing unexpected rejections.
~all: The Soft Fail Qualifier
The ~all qualifier (pronounced "tilde all" or "softfail") represents a soft fail. When an email fails SPF authentication with ~all, receiving servers mark it as suspicious but don't necessarily reject it. The email is typically delivered but marked with a warning or flag.
v=spf1 include:_spf.google.com ~all
With this configuration, emails failing SPF authentication are treated as questionable but still delivered. Users might see warnings like "this email is suspicious" or "failed SPF checks," but they'll receive the email.
The advantages of ~all:
Better Deliverability - You avoid false positives where legitimate emails are completely rejected.
Gradual Rollout - You can implement SPF monitoring and catch issues before deploying hard fail.
Flexibility - You maintain ability to send through backup or emergency mail servers if needed.
The disadvantages:
Reduced Phishing Protection - Phishing emails claiming to come from your domain aren't rejected, they're just marked suspicious.
User Confusion - Warnings about failed SPF checks can confuse users who don't understand email authentication.
Guidance on Choosing Between -all and ~all
The decision depends on your organization's priorities and email infrastructure maturity:
Use -all if:
You have a mature, well-documented email infrastructure where every system sending email on your behalf is known and included in SPF.
You want maximum protection against domain spoofing and are willing to closely monitor and immediately address any legitimate emails that fail SPF.
Your domain is a common phishing target (executive email domain, financial institution, etc.) where protection outweighs deliverability concerns.
All your email comes from known, stable sources that are unlikely to change.
Use ~all if:
You're just implementing SPF and need time to discover all systems sending email on your behalf.
You have complex forwarding scenarios, third-party integrations, or legacy systems that might cause false positives with -all.
You want to monitor SPF effectiveness before deploying hard fail.
You have users with external email addresses or frequent delegation scenarios.
You're experiencing deliverability issues and need to diagnose whether SPF is the cause.
The Transition Path: Starting with ~all
Many security professionals recommend starting with ~all and transitioning to -all over time. This approach provides early protection while avoiding false positives. The order matters — turn on reporting first, learn who sends for you, then tighten:
This approach provides early protection while avoiding false positives:
Phase 1: Baseline with ~all
v=spf1 include:_spf.google.com ~all
Deploy this and monitor which emails fail SPF checks. This reveals your complete email infrastructure.
Phase 2: Monitor and Document
For several weeks, monitor SPF failure reports and logs. Document every system and service that sends email on your behalf. Update your SPF record to include any legitimate services that aren't already listed.
Phase 3: Expand Include Rules
Add any discovered services to your SPF record with additional include or ip4/ip6 directives. Make sure every legitimate email source is explicitly authorized.
Phase 4: Deploy -all
Once you're confident all legitimate email sources are included and failures drop to near-zero, transition to -all:
v=spf1 include:_spf.google.com -all
This transition approach gets you protection while minimizing the risk of breaking legitimate email.
DMARC Policy: The More Important Qualifier
While choosing between -all and ~all is important, it's worth noting that DMARC policy provides more sophisticated control. DMARC allows you to specify what receiving mail servers should do with emails that fail SPF or DKIM authentication:
v=DMARC1; p=reject; sp=none
This DMARC policy says "reject emails that fail alignment" (the main policy p=reject), while "subdomains can use a more lenient policy" (sp=none).
DMARC's flexibility means you don't have to choose between absolute hard fail and complete permissiveness. You can specify different policies for different scenarios. Many organizations use ~all in SPF while using p=reject in DMARC, providing a more nuanced authentication strategy.
Common Mistakes in SPF Configuration
Not Including All Email Sources - Forgetting to include a service that sends email (like monitoring systems, accounting software, or backup services) causes false failures. This is why starting with ~all and monitoring is recommended.
Using ? instead of ~ - The ? qualifier (neutral/pass-through) provides no protection and shouldn't be used for the final qualifier unless you explicitly want to claim "we don't care."
Setting -all Too Aggressively - Implementing -all without fully understanding your email sources causes legitimate emails to fail.
Not Monitoring SPF Results - Setting SPF and forgetting to monitor its effectiveness means you might not notice when emails fail unexpectedly.
SPF Limits and Workarounds
SPF records have a 255-character limit and a maximum of 10 DNS lookups. Large organizations with many email sources sometimes hit these limits. Solutions include:
Consolidation - Combine services under single includes where possible.
Optimization - Remove unnecessary includes and consolidate similar services.
Nested Includes - Create subdomain SPF records that include other includes, counting as one lookup each.
Example of optimization:
v=spf1 include:_spf.all-our-vendors.com ~all
Instead of including each vendor separately, include a single record that contains all vendor SPF includes.
Email Authentication Best Practices
For comprehensive email authentication:
SPF - Specify authorized mail servers (current approach discussed here)
DKIM - Digitally sign emails so they can be verified (complements SPF)
DMARC - Policy that determines what happens when SPF/DKIM fail (provides reporting)
Together, these create a strong email authentication system. SPF's -all vs ~all choice is important, but it's just one piece of a comprehensive email security strategy.
Making Your Decision
Choose -all if you have high confidence in your SPF configuration and need maximum protection. Choose ~all if you're implementing SPF for the first time, have complex email infrastructure, or need to balance security with deliverability. Plan to monitor either way, and be prepared to adjust as your email infrastructure evolves.
Most importantly, don't leave your domain unprotected. Even ~all is substantially better than no SPF at all, as it prevents at least some SPF spoofing attacks and provides valuable monitoring data. Start with ~all, gain experience and confidence, then transition to -all once your infrastructure is fully documented and tested.