Skip to main content

SPF Soft Fail (~all)

Your domain uses a soft fail policy, which flags unauthorized emails as suspicious but doesn't reject them. Here's why you should upgrade to hard fail for stronger protection.

What is soft fail (~all)?

The ~all mechanism at the end of an SPF record is called a "soft fail." It tells receiving mail servers that emails from senders not listed in your SPF record are probably not authorized, but should be accepted anyway and marked as suspicious.

v=spf1 include:_spf.google.com ~all

The ~ prefix on all is what makes this a soft fail. Compare this to -all (hard fail), which instructs receiving servers to outright reject unauthorized emails.

In practice, soft fail means an attacker who spoofs your domain will have their emails flagged but potentially still delivered to recipients' inboxes or spam folders. This is a significant gap in your email security.

Why soft fail is weaker than hard fail

The difference between ~all and -all is critical for email security. Here's how receiving mail servers handle each:

Scenario ~all (soft fail) -all (hard fail)
Unauthorized server sends email as your domain Email accepted but flagged as suspicious Email rejected outright
Where unauthorized email ends up Spam folder or sometimes inbox Bounced back; never delivered
Phishing protection Partial — recipients may still see spoofed email Strong — spoofed email never reaches recipients
Recommended for Initial testing and rollout only Production use
⚠️
The risk of staying on ~all: Attackers know that soft fail domains are easier to spoof. Phishing emails sent from your domain may land in recipients' spam folders, but some email clients display spam folder contents prominently, and users often check their spam. Even a single opened phishing email can lead to credential theft or financial loss.

Why people use ~all

Soft fail was originally designed as a transitional policy, and there are legitimate reasons it might be in your SPF record:

🔍

Testing phase

When first setting up SPF, administrators often use ~all to identify any legitimate senders they may have missed before switching to hard fail.

📨

Email forwarding concerns

Traditional email forwarding can break SPF because the forwarding server's IP isn't in the original domain's SPF record. However, modern standards like SRS (Sender Rewriting Scheme) solve this.

📋

Provider defaults

Some email providers suggest ~all in their setup guides as a conservative default. This is unnecessarily cautious for most deployments.

Never got around to it

Many domains started with ~all during rollout and simply never upgraded. If your SPF record has been stable for months, it's time to switch.

How to upgrade from ~all to -all

Upgrading from soft fail to hard fail is straightforward. Follow these steps to do it safely:

1

Audit your current senders

Make a list of every service that sends email from your domain: your email provider (Google Workspace, Microsoft 365), marketing tools (Mailchimp, SendGrid), CRM (Salesforce, HubSpot), helpdesk (Zendesk), and any custom applications.

2

Check your DMARC reports

If you have DMARC set up with reporting (rua), review your aggregate reports to see which servers are sending email as your domain and whether they're passing or failing SPF. This reveals any legitimate senders missing from your record.

3

Verify all senders are in your SPF record

Confirm that every legitimate sending service has a corresponding include or ip4/ip6 entry in your SPF record. Add any that are missing.

4

Update your DNS record

Log into your DNS provider and edit your SPF TXT record. Change ~all to -all. The rest of the record stays the same.

5

Monitor for issues

After making the change, monitor your DMARC reports and email delivery for a few days. If a legitimate sender is being rejected, add them to your SPF record immediately.

💡
Quick change: If your SPF record has been stable with ~all for several months and you haven't seen any issues, the upgrade is typically as simple as changing one character in your DNS record: ~ to -.

Provider-specific notes

Google Workspace

Google's documentation sometimes shows ~all in examples, but they fully support -all. If you're only using Google Workspace for email, switching to hard fail is safe and recommended.

v=spf1 include:_spf.google.com -all

Microsoft 365

Microsoft's setup guides sometimes suggest ~all for initial configuration. Once you've verified your email is flowing correctly, upgrade to -all. Microsoft 365 works perfectly with hard fail.

v=spf1 include:spf.protection.outlook.com -all

Multiple services

If you use multiple email services, make sure all of them are included before switching to hard fail. Here's an example combining several services:

v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com -all

Before and after examples

Here's exactly what the change looks like for common configurations:

Before (soft fail)

v=spf1 include:_spf.google.com ~all

After (hard fail)

v=spf1 include:_spf.google.com -all

Before (multiple services, soft fail)

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

After (multiple services, hard fail)

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all
💡
DNS propagation: After updating your SPF record, allow up to 48 hours for DNS changes to propagate worldwide, though most changes take effect within a few hours. During this period, some servers will see the old record and some will see the new one.

For a comprehensive overview of SPF, including all mechanisms, qualifiers, and common mistakes, see our complete guide to SPF.

Upgrade your SPF and let us monitor it

Domain Guarddog monitors your SPF, DKIM, and DMARC configuration and alerts you when issues arise or records change.

Get Started Free