Understanding SPF Qualifiers: -all vs ~all
The difference between -all and ~all in SPF (Sender Policy Framework) records represents one of the most important email authentication decisions. The choice affects how aggressively your domain enforces SPF policy—either definitively rejecting mail that fails authentication or softly failing it. Understanding this distinction and choosing the right qualifier for your situation is crucial for preventing phishing while maintaining email deliverability.
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.
-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, the receiving mail server should reject the email completely.
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, the receiving server will reject it. This is the most aggressive SPF posture, providing maximum protection against spoofing.
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:
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.
