SPF Hard Fail (-all) Explained
Your domain uses the strictest SPF policy available. Hard fail tells receiving mail servers to reject any email that doesn't come from your authorized senders.
What is hard fail (-all)?
The -all mechanism at the end of an SPF record is called a "hard fail." It tells
receiving mail servers that any email from your domain that doesn't match one of the authorized
mechanisms in your SPF record should be rejected outright.
This is the most protective SPF policy you can set. It sends a clear signal: "If the sending server isn't on my list, this email is not from me. Do not deliver it."
v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all
The - prefix on all is what makes this a hard fail. Compare this to
~all (soft fail), which only flags unauthorized emails as suspicious rather than
rejecting them.
How hard fail protects you
When a receiving mail server gets an email claiming to be from your domain, it evaluates your SPF record from left to right:
Sender IP is extracted
The receiving server looks at the IP address of the server that delivered the email and extracts the domain from the Return-Path header.
SPF record is retrieved
The server queries your domain's DNS for a TXT record starting with v=spf1.
Mechanisms are checked in order
Each mechanism (include, ip4, mx, etc.) is checked against the sender's IP. If one matches, the result is "pass."
No match reaches -all
If no mechanism matches, evaluation reaches -all. The result is "fail" and the receiving server is instructed to reject the email.
What happens to unauthorized emails
When an unauthorized server tries to send email using your domain and your SPF record ends with
-all, the receiving server will typically take one of these actions:
| Action | Description |
|---|---|
| Reject (bounce) | The email is rejected during the SMTP transaction. It never reaches the recipient's inbox or spam folder. This is the most common response to a hard fail. |
| Discard silently | Some servers accept the email but silently discard it without delivering it. The sender receives no bounce notification. |
| Mark and quarantine | A few servers may still deliver the email to spam or quarantine, though this behavior is less common with hard fail than with soft fail. |
-all, most major email
providers (Google, Microsoft, Yahoo) will reject unauthorized emails. With ~all,
those same emails are more likely to be delivered to spam rather than rejected entirely. Hard fail
provides a much stronger defense against spoofing.
Example SPF records with -all
Here are common SPF configurations that use the recommended hard fail policy:
Google Workspace only
v=spf1 include:_spf.google.com -all
Microsoft 365 only
v=spf1 include:spf.protection.outlook.com -all
Google Workspace with a marketing platform
v=spf1 include:_spf.google.com include:sendgrid.net -all
Custom mail server with specific IPs
v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 -all
Multiple services combined
v=spf1 include:_spf.google.com include:amazonses.com include:sendgrid.net -all
Remember that SPF has a 10 DNS lookup limit. Each include uses at least one lookup, plus any nested lookups within the included record.
Your domain is well-configured
-all (hard fail),
which is the strongest SPF policy available. This means unauthorized servers that attempt to
send email from your domain will be rejected by receiving mail servers. You're following email
security best practices.
Having -all in your SPF record is the gold standard for SPF configuration. It provides
the clearest signal to receiving servers that only the senders you've explicitly listed are authorized.
SPF hard fail is active
Your -all policy tells receivers to reject unauthorized emails. This is the recommended configuration.
Maintaining your SPF record
Even though your SPF record is well-configured, it's important to keep it up to date as your email infrastructure changes. Here are some things to watch for:
Add new senders before deploying
When you start using a new email service (marketing platform, CRM, helpdesk), add their SPF include to your record before sending your first email through them.
Remove old services
If you stop using an email service, remove its include from your SPF record. This reduces your DNS lookup count and tightens your policy.
Watch the 10 DNS lookup limit
Each include, a, mx, exists, and redirect mechanism counts toward the 10-lookup limit. Exceeding it causes a permanent error.
Combine with DKIM and DMARC
SPF is just one pillar of email authentication. Pair it with DKIM for message integrity and DMARC for policy enforcement and reporting.
Monitor DMARC reports
Use DMARC aggregate reports (rua) to track SPF pass/fail rates across all your sending sources. This helps you catch unauthorized use of your domain.
For a comprehensive overview of SPF, including all mechanisms, qualifiers, and common mistakes, see our complete guide to SPF.
Keep monitoring your domain's email security
Domain Guarddog continuously monitors your SPF, DKIM, and DMARC configuration and alerts you to any changes or issues.
Get Started Free