SPF Hard Fail vs Soft Fail: -all vs ~all

Every SPF record ends with an all mechanism that tells receiving servers what to do with messages from unlisted sources. The qualifier you put in front of it — - for hard fail or ~ for soft fail — determines how strictly that policy is enforced.

This is one of the most common SPF decisions, and the answer is not as obvious as it seems.

The Comparison

What Hard Fail (-all) Means

A hard fail tells receiving servers: "If the sending IP is not in my SPF record, reject the message outright." It is the strictest policy.

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

In theory, -all means unauthorized messages should be rejected. In practice, many receivers treat hard fail as a strong negative signal rather than an absolute rejection. Gmail, for example, may still deliver a hard-failed message to spam rather than bouncing it. But other receivers, particularly smaller or corporate mail servers, may reject it outright.

What Soft Fail (~all) Means

A soft fail tells receiving servers: "If the sending IP is not in my SPF record, be suspicious but do not reject it." The message should be accepted but treated with extra scrutiny.

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

Most receivers use soft fail as one input among many in their spam scoring. A soft-failed message will not be rejected outright, but it will score worse and may end up in spam, especially if other signals (DKIM, DMARC, reputation) are also negative.

How Receivers Actually Handle Each

The SPF RFC defines what -all and ~all mean, but receivers are free to interpret them however they choose. Here is what actually happens in practice:

Major providers (Gmail, Outlook, Yahoo):

• -all and ~all are treated very similarly. Both result in the message being flagged but not necessarily rejected. DMARC policy is the more decisive factor.
• With DMARC p=reject, both hard fail and soft fail lead to rejection if DKIM also fails alignment.

Corporate and smaller servers:

• -all is more likely to cause outright rejection, especially if the server does not check DMARC.
• ~all almost always results in delivery (possibly to spam) rather than rejection.

When to Use Soft Fail (~all)

Soft fail is the recommended default for most domains. Use it when:

• You are setting up SPF for the first time. You may not have identified every legitimate sending source yet. Soft fail gives you a safety net while you audit.
• You use many third-party senders. Marketing platforms, CRMs, ticketing systems, transactional email services — the more senders you have, the higher the risk of missing one.
• You are rolling out DMARC gradually. During the p=none monitoring phase (you can set this up with DMARC Creator), soft fail lets you collect data without risking delivery.
• You are not sure. When in doubt, soft fail is the safer choice. You can always tighten it later.

When to Use Hard Fail (-all)

Hard fail makes sense when:

• You have a complete inventory of all sending sources. You are confident that every server and service that sends email for your domain is listed in your SPF record.
• You have tested with soft fail first. You have run ~all for weeks or months, monitored DMARC reports (the Email Deliverability Suite can help you track this), and confirmed no legitimate email is failing SPF.
• You want maximum protection on a non-sending domain. For domains that should never send email at all, -all with no authorized sources is the right call: v=spf1 -all
• You have DMARC at p=reject. If your DMARC policy already rejects failures, -all adds another layer but is not strictly necessary.

Neutral (?all) Explained

The neutral qualifier ?all tells receivers that you have no opinion about unlisted sources. It is equivalent to having no SPF record at all as far as the all mechanism is concerned.

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

Neutral is rarely the right choice. It was intended for domains that wanted to publish SPF information without making a policy statement, primarily useful during the early days of SPF adoption. Today, there is no practical reason to use ?all on a production domain. Use ~all at minimum.

DMARC Interaction

How your SPF all mechanism interacts with DMARC is important:

• DMARC p=none: SPF result is reported but does not affect delivery. Both -all and ~all behave the same in practice.
• DMARC p=quarantine: SPF failure (combined with DKIM failure) causes messages to be sent to spam. The hard/soft distinction matters less because DMARC is making the policy decision.
• DMARC p=reject: SPF failure (combined with DKIM failure) causes messages to be rejected. Again, DMARC overrides the SPF-level policy distinction.

If you are deploying DMARC (and you should be), the practical difference between -all and ~all shrinks significantly. DMARC becomes the enforcement mechanism, not SPF alone. Make sure you also have DKIM configured — DMARC requires either SPF or DKIM to pass with alignment, so having both gives you a fallback.

Bottom Line

Start with ~all (soft fail). It is the safer default that protects you from accidental rejections while still providing a meaningful authentication signal. Move to -all (hard fail) only after you have confirmed every legitimate source is covered, ideally by monitoring DMARC reports for several weeks. You can verify your current SPF record and fail policy with SPF Record Check. For domains that never send email, use v=spf1 -all immediately.

The all mechanism is your safety net. Set it thoughtfully.

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.