SPF "all" Mechanism: Softfail vs Hardfail Explained

Every SPF record ends with an all mechanism. It's the most important part of your record because it tells receiving mail servers what to do with emails that don't match any of your authorized sources. Get it wrong, and you either leave your domain open to spoofing or accidentally block legitimate emails.

This guide explains what all does, breaks down each qualifier, and helps you choose the right one for your domain.

What the "all" Mechanism Does

The all mechanism, as defined in RFC 7208, is a catch-all. It matches every sending IP address that wasn't already matched by an earlier mechanism in your record (like include, ip4, a, or mx).

Think of your SPF record as a checklist. When a receiving server evaluates it, the server goes through each mechanism from left to right, checking whether the sending IP matches. If the IP matches an include, ip4, or other mechanism, the evaluation stops and returns a result. If the IP doesn't match anything, the server reaches all at the end and uses whatever qualifier is attached to it.

In this record:

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

The server checks Google's IP ranges first, then the specific IP 203.0.113.10. If the sending IP matches neither, it hits ~all and returns a softfail.

The Four Qualifiers

The all mechanism is always paired with a qualifier that determines the result. There are four possible qualifiers, each with very different implications.

+all (Pass) -- Never Use This

v=spf1 +all

This tells receiving servers that every server on the internet is authorized to send email for your domain. It completely defeats the purpose of SPF. Never use +all.

-all (Hardfail)

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

Hardfail is the strictest option. It tells receiving servers: "If an email comes from a server not listed in my SPF record, reject it." Many receiving servers will reject the email outright or send it to spam. The exact behavior depends on the receiving server's policies and whether you have a DMARC policy.

Best for: Domains where you're confident your SPF record is complete. Also ideal for domains that don't send email at all (v=spf1 -all).

~all (Softfail)

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

Softfail is the most commonly used qualifier. It tells receiving servers to treat unauthorized emails with suspicion, but not necessarily reject them. Most servers will factor it into spam scoring rather than blocking outright.

Best for: Most domains, especially if you're still setting up or aren't 100% sure you've listed every legitimate sending source.

?all (Neutral)

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

Neutral tells receiving servers you have no opinion about unlisted servers. It provides minimal authentication value. Rarely useful. Use ~all if you're not ready to enforce, or -all if you are.

Softfail vs Hardfail: Which Should You Use?

This is the most common question people have about the all mechanism. Here's a practical framework for deciding.

Start with ~all (Softfail)

If you're setting up SPF for the first time or making changes to your record, start with ~all. This gives you a safety net while you verify that everything is configured correctly.

With softfail, emails from unlisted servers won't be outright rejected. This means that if you forgot to include a legitimate service, those emails will still have a chance of being delivered (though they may land in spam). You can monitor your DMARC reports to catch any legitimate sources you missed.

Move to -all (Hardfail) When You're Ready

Once you've confirmed that your SPF record includes all legitimate sending sources, switch to -all. This gives you the strongest protection against spoofing.

How "all" Interacts with DMARC

Without DMARC, the all qualifier is the primary signal, but receiving servers make their own decisions about enforcement.

With DMARC, the combination is more powerful. When you have p=reject in your DMARC policy and -all in SPF, you're sending a clear signal: unauthorized emails should be blocked. Read SPF, DKIM, and DMARC Explained for a complete overview.

What About Email Forwarding?

When someone forwards your email, the forwarding server's IP is what the receiving server sees, and that IP won't be in your SPF record. With -all, forwarded emails hardfail. With ~all, they get a softer treatment.

This is another reason to keep ~all until you have DKIM properly configured. DKIM survives forwarding because it's based on message content, not the sending server's IP. Learn more in SPF and Email Forwarding. For the full picture on how SPF, DKIM, and DMARC work together, see our complete SPF guide.

Common Mistakes

Forgetting all entirely. An SPF record without an all mechanism is incomplete:

v=spf1 include:_spf.google.com

This is technically valid but provides no guidance on what to do with unauthorized senders. Always include an all mechanism at the end.

Putting all in the middle of the record. The all mechanism matches everything. Any mechanisms after it will never be evaluated:

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

This effectively means "softfail everything" because ~all matches before include is ever checked. Always put all last.

Using +all thinking it means "allow all my listed servers." The + qualifier means pass, and all matches everything. Together, +all authorizes the entire internet. If you want to authorize only your listed servers, use -all or ~all after them.

Switching to -all too quickly. Moving to hardfail before you've identified all legitimate sending sources will cause those sources to fail SPF. Take your time, monitor with DMARC, and switch only when you're confident.

If you need help building or fixing your SPF record, SPF Creator generates records with the correct syntax and your choice of qualifier.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification, including qualifier and all mechanism definitions
• RFC 7489: DMARC — How DMARC interacts with SPF results