Email authentication plays a foundational role in protecting your domain, your brand reputation, and your users from phishing, spoofing, and other malicious activity. Among the core authentication technologies — SPF, DKIM, and DMARC — SPF (Sender Policy Framework) is often one of the first layers of defense domain owners implement. However, even after publishing an SPF record, many administrators still struggle with a critical part of SPF syntax: the “all” mechanism.
In this guide, AutoSPF will break down:
✅ What SPF is and why it matters
✅ What the “all” mechanism actually does
✅ The differences between the common qualifiers (-all vs ~all, and others)
✅ Best practices for choosing and deploying your SPF policy
✅ Real-world impacts on email deliverability and security
Our goal is not just to describe SPF, but to help you make the right decisions for your domain’s security posture.
Understanding SPF: The Basics
At its core, SPF is a DNS-based policy that tells receiving mail servers which IP addresses and sending services are authorized to send mail on behalf of your domain. When a message is received, the recipient’s server checks the SPF record associated with the domain in the “MAIL FROM” (also known as Return-Path or Envelope From) address. If the sending IP is listed, the message “passes” SPF; if not, it “fails” or “soft-fails” depending on the configuration.
An SPF record looks like a simple text (TXT) entry in DNS that starts with a version indicator (v=spf1) and lists all authorized mechanisms such as ip4, ip6, include, a, and mx. The SPF record almost always ends with an “all” mechanism.
Here’s a basic example:
v=spf1 ip4:192.0.2.0/24 include:_spf.sendgrid.net ~all
In this record:
- v=spf1 — Defines the SPF version
- ip4:192.0.2.0/24 — Authorizes a subnet of IPv4 addresses
- include:_spf.sendgrid.net — Authorizes SendGrid’s servers
- ~all — Defines how to handle senders not listed (more on this soon)
The “all” Mechanism — Why It’s Critical
Unlike other parts of an SPF record that define who is authorized, the “all” mechanism defines the default policy for all senders not explicitly matched by earlier rules. As such, it’s a catch-all clause and generally must be placed at the end of your SPF text.
If you omit an all mechanism, the SPF validation will still happen, but for any IP not matched earlier, the result may be interpreted as neutral or none — effectively giving no instruction to the receiving mail server. This ambiguity can undermine your domain’s security.
Because the “all” mechanism determines how unlisted senders are handled, the qualifier you choose for it has real-world implications for email flow, security, and deliverability.
SPF Qualifiers — What They Mean
The action taken by an SPF policy depends on the qualifier you place before the all mechanism. There are four possible qualifiers (the default if unspecified is equivalent to +all):
| Qualifier | Name | What It Means |
| -all | Hard Fail | Reject emails from non-listed senders |
| ~all | Soft Fail | Accept but mark/flag emails from non-listed senders |
| ?all | Neutral | Treat non-listed senders neutrally |
| +all | Pass | Always allow mail, even unauthorized |
Here’s how each works in practice:
-all (Hard Fail)
When you end your record with -all, you are telling receiving MTAs (Mail Transfer Agents):
“Any mail not coming from a listed sender should be rejected outright.”
This is the strictest SPF policy and provides the highest level of protection against unauthorized outgoing mail — but only if your SPF list is complete.
Pros:
✔ Maximum security
✔ Clear instruction for rejecting spoofed senders
Cons:
✘ Can cause legitimate mail to be rejected if you miss a sending source
✘ Can interfere with email forwarding or third-party sending flows if not properly accounted for
~all (Soft Fail)
With ~all, you are instructing:
“Treat mail from non-matching senders as soft failures — accept them, but mark as suspicious.”
This is a more flexible policy for domains that may have complex email sending infrastructure or aren’t confident that every sending source is listed.
Pros:
✔ Better deliverability during testing or multi-vendor sending
✔ Helps debug SPF mismatches without mail being dropped
✔ Works well with DMARC policies to enforce alignment
Cons:
✘ Does not enforce rejection of spoofed senders on its own
✘ Relies on receiving servers to interpret the softfail appropriately
?all (Neutral)
This qualifier effectively says “I am not declaring a policy here.” It’s most useful when you’re in the process of building your SPF and want to ensure deliverability while you gather data.
Pros:
✔ No risk of losing legitimate mail
✔ Useful during initial stages of deployment
Cons:
✘ Provides no security benefit
✘ Essentially the same as not having an SPF policy for unlisted senders
+all (Pass)
Putting +all at the end literally tells receivers to allow everything — which defeats the purpose of SPF entirely. It’s almost never recommended outside of testing or placeholder entries.
-all vs ~all: Which Should You Use?
This is the key question many administrators have — and the answer isn’t one-size-fits-all. The best choice depends on your email environment and goals.
Use ~all When:
✔ You are not yet certain every sending source is included
✔ You use multiple third-party mail services (marketing, newsletters, support systems)
✔ You want to minimize the risk of legitimate mail being blocked
✔ You’re in the early stages of DMARC deployment and gathering SPF data
Soft fails allow receiving MTAs to deliver the mail (often in spam/junk) but still indicate something is wrong. This can be helpful for troubleshooting and ensuring your SPF record is correct before enforcing stricter policies.
Use -all When:
✔ You have enumerated all sending sources with confidence
✔ You want the strictest rejection of unauthorized mail
✔ You are using an enforced DMARC policy (p=reject) and have tested thoroughly
✔ You are certain that forwarding and third-party flows are accounted for
This approach delivers the highest security but has the biggest impact on deliverability if anything is missing or misconfigured.
How SPF Works With DMARC
An important nuance that often gets overlooked is how SPF interacts with DMARC — a policy that tells receiving mail servers how to act on mail that fails SPF and/or DKIM. When you have a DMARC policy in place (p=quarantine or p=reject), the behavior of ~all vs -all changes in practical effect.
Here’s how:
- With DMARC in enforce mode, SPF soft fails can still result in alignment failures, but the overall enforcement is handled by DMARC — so your ~all doesn’t weaken overall domain protection.
- In scenarios like forwarded mail or indirect mail flows, a strict -all can cause messages to be rejected before DMARC is evaluated, which might block mail that would otherwise pass DMARC via DKIM.
So even if you are using ~all, DMARC enforcement ensures unauthorized mail is handled according to your larger email policy.
Common SPF Mistakes to Avoid
At AutoSPF, we see several classic pitfalls:
🔹 Omitting the all mechanism – Leaving an SPF record without an explicit ‘all’ can have unpredictable results.
🔹 Using +all in production – This basically turns off SPF protection.
🔹 Listing only some sending services – If you miss a vendor’s sending IPs, you’ll create false negatives under -all.
🔹 Forgetting includes for third-party services – If you use multiple platforms to send mail, ensure they are included properly.
How AutoSPF Helps You Get SPF Right
Because SPF records can grow complex quickly — especially for domains that send mail through multiple services — AutoSPF provides tools that automatically:
✨ Flatten SPF includes to stay under lookup limits
✨ Validate that your SPF record is syntactically and logically correct
✨ Suggest optimal qualifiers based on your sending footprint
With AutoSPF’s automated analysis, you can reduce errors and confidently deploy SPF policies that both protect your domain and maintain high deliverability.
