BounceCheckBounceCheck
    • Features
      Bulk Email Verification
      Verify thousands of emails at once
    • Tools
      Disposable Email Checker
      Detect throwaway email domains
      Email Extractor
      Extract emails from any text or file
      DNS Health Checker
      Check MX, SPF, DMARC, DKIM & blacklists
    • Pricing
    • Compare
    • Blog
    • Docs
    Sign inStart Free
    Back to The Field Guide
    § Email Deliverability

    SPF ~all vs -all: Softfail vs Hardfail Explained (2026)

    B
    BounceCheck Team
    July 21, 2026
    5 min read
    SPF authentication showing the all mechanism with softfail and hardfail qualifiers

    In an SPF record, ~all (softfail) and -all (hardfail) are the closing mechanism that tells a receiving server what to do with mail from a server that is not on your authorized list. ~all says the message is probably not authorized, so accept it but treat it as suspicious. -all says it is definitely not authorized, so reject it. Use -all for the strongest protection once your SPF record is complete and correct, and ~all while you are still testing and do not want to risk dropping legitimate mail.

    What do ~all and -all mean in an SPF record?

    An SPF record ends with the all mechanism, which always matches any sending IP that none of the earlier mechanisms already covered. The qualifier in front of all decides the result for those unlisted senders. SPF defines four qualifiers in RFC 7208: + (pass), - (fail), ~ (softfail), and ? (neutral).

    Comparison diagram of SPF hard fail and soft fail handling

    ~all is a softfail. It is a weak statement that the host is probably not authorized, because the domain has not published a stronger, more definitive policy. The intended action is to accept the message but mark it, which usually means routing it to spam or flagging it as suspicious rather than rejecting it.

    -all is a hardfail, written as fail in SPF results. It is an explicit statement that the sender is not authorized to use the domain. Receiving servers that honor a hardfail reject the message outright, though the actual behavior varies from one server to another.

    For context, +all authorizes every server on the internet to send as your domain, which is highly discouraged, and ?all (neutral) asserts nothing at all about unlisted senders. Almost every real record uses ~all or -all.

    SPF ~all vs -all: the key differences

    The two qualifiers differ in the verdict they publish, how a receiver acts on it, and how consistently that verdict travels through DMARC.

    Attribute ~all (softfail) -all (hardfail)
    SPF result Softfail Fail
    Statement Probably not authorized Definitely not authorized
    Intended action Accept but mark (spam or suspicious) Reject
    DMARC interpretation Pass or fail, depends on the receiver's config Fail, consistently across packages
    Best for Setup and testing phases A finished, verified record

    The DMARC row is the one that trips people up. A -all result is interpreted as fail in every DMARC implementation, so the outcome is predictable everywhere. A ~all result can be treated as either pass or fail depending on how the receiving server configures DMARC. In OpenDMARC, for example, both softfail and neutral are treated as fail by default, but that behavior can be changed.

    Which should you use, ~all or -all?

    Diagram showing the anatomy of an SPF record and its mechanisms

    Use -all once you are confident your SPF record lists every service that sends mail for your domain. It is the strongest signal, it protects your domain from spoofing most effectively, and it produces the same fail verdict on every receiver. This is the goal state for a production domain.

    Use ~all as a safer interim setting while you build and verify the record. If you switch to -all before you have accounted for every sender, such as a help desk, a CRM, or a marketing platform, receivers that honor the hardfail will reject that legitimate mail. A softfail sends the same "unauthorized" signal without the hard rejection, which buys you time to catch a missing sender in your DMARC reports before it costs you delivered mail.

    The trade-off is real. ~all is more forgiving but weaker against spoofing, while -all is stronger but unforgiving of an incomplete record. The usual path is to publish ~all first, monitor, then tighten to -all. Getting there is part of a wider SPF, DKIM, and DMARC setup, not a single switch.

    How mailbox providers treat ~all and -all

    Mailbox providers decide for themselves whether to reject on -all or only penalize on ~all, so the same qualifier can be handled differently from one provider to the next. Large providers generally weigh the SPF result alongside DKIM and DMARC rather than acting on the SPF qualifier alone.

    Sending platforms reflect this in the records they recommend. Google and Mailgun suggest ~all, SendGrid publishes with ~all, and some platforms such as MailChimp and Mandrill historically used ?all. If you send through a provider, follow the record it gives you, and if you add the SendGrid SPF record or any other service, fold its include into your single record rather than publishing a second one.

    Why SPF can cause your mail to be rejected

    An SPF record checking tool validating a domain's SPF syntax

    If your own mail is being rejected on SPF, a -all record combined with a sender you forgot to authorize is the most common cause. The receiver looks up your record, finds the sending IP is not listed, hits the -all, and rejects the message. A few other issues produce the same failure:

    • The sending IP or service is genuinely missing from the record, so a legitimate stream fails.
    • The record has more than 10 DNS lookups, which returns a permerror that many receivers treat as a failure.
    • There are two SPF records on the domain, which is invalid and also returns a permerror.
    • The record has a syntax error, so it cannot be evaluated.

    Fixing SPF is one part of landing in the inbox rather than the spam folder. Clean authentication paired with a clean list is how you improve email deliverability, and the Gmail sender guidelines spell out what large receivers now expect.

    FAQs

    What is the difference between softfail and hardfail in SPF?

    Softfail (~all) tells receivers a message from an unlisted server is probably unauthorized, so accept it but mark it as suspicious or route it to spam. Hardfail (-all) declares it definitely unauthorized, so reject it. Hardfail is stronger; softfail is more forgiving of an incomplete record.

    Is ~all or -all better for security?

    -all is better for security because it produces a consistent fail verdict that instructs receivers to reject unauthorized mail, which limits spoofing. ~all is weaker but safer while you are still confirming every legitimate sender is listed, since it will not reject mail you forgot to include.

    Does ~all send mail to spam?

    Often, yes. A softfail result is not a rejection, but many receivers treat it as a strong spam signal and file the message in the spam folder or flag it. The exact handling depends on the receiving server and its DMARC configuration.

    Should I use ~all or -all with DMARC?

    -all pairs most cleanly with DMARC because it is interpreted as fail on every implementation, giving you predictable results. ~all can be read as pass or fail depending on the receiver, so once your record is verified and DMARC is monitored, tightening to -all removes that ambiguity.

    What does +all do in an SPF record?

    +all authorizes any server on the internet to send email as your domain, which effectively disables SPF protection. It is highly discouraged and should never appear on a domain you care about.

    Before your next send, run your list through BounceCheck to remove the invalid addresses that hard-bounce, so a clean SPF record is not the only thing standing between you and the inbox.

    B

    BounceCheck Team

    The team behind BounceCheck - helping businesses verify emails and improve deliverability.

    • What do ~all and -all mean in an SPF record?
    • SPF ~all vs -all: the key differences
    • Which should you use, ~all or -all?
    • How mailbox providers treat ~all and -all
    • Why SPF can cause your mail to be rejected
    • FAQs
    • What is the difference between softfail and hardfail in SPF?
    • Is ~all or -all better for security?
    • Does ~all send mail to spam?
    • Should I use ~all or -all with DMARC?
    • What does +all do in an SPF record?

    More Articles

    Explore guides on email deliverability, verification, and sender reputation.

    Browse All Articles

    § KEEP READING

    You might also like.

    Types of Email Accounts: Protocols and Mailbox Types
    § Email DeliverabilityJul 21, 2026· 5 min read

    Types of Email Accounts: Protocols and Mailbox Types

    Email accounts split by connection protocol (POP, IMAP, Exchange, SMTP) and by mailbox purpose (personal, shared, role-based, and more). Here is how each type works and where it fits.

    By BounceCheck TeamRead →
    Google Workspace SPF Record: The Default Value and How to Set It Up
    § Email DeliverabilityJul 21, 2026· 5 min read

    Google Workspace SPF Record: The Default Value and How to Set It Up

    The default Google Workspace SPF record is v=spf1 include:_spf.google.com ~all. What it means, how to add it in DNS, and how to include other senders.

    By BounceCheck TeamRead →
    DKIM temperror: What It Means and How to Fix It (2026)
    § Email DeliverabilityJul 21, 2026· 5 min read

    DKIM temperror: What It Means and How to Fix It (2026)

    A DKIM temperror means a receiving server hit a temporary DNS problem while checking your signature. Learn what causes it and how to fix it.

    By BounceCheck TeamRead →

    § COLOPHON

    Email verification, made simple. Built for teams who care about clean data and clean code.

    § STATUS

    All systems operational
    BounceCheckBounceCheck

    Real-time email verification with a stealth SMTP engine. Built for deliverability obsessives.

    § PRODUCT

    • Features
    • Bulk Email Verification
    • Single Verify
    • Real-Time API
    • Integrations

    § TOOLS

    • Email Extractor
    • Disposable Email Checker

    § RESOURCES

    • Docs
    • Blog
    • Compare
    • Security
    • Pricing

    § COMPANY

    • About
    • Contact
    • Privacy
    • Terms

    © 2026 BounceCheck — All rights reserved.

    GDPRCCPAENCRYPTEDPRIVATE