SPF ~all vs -all: Softfail vs Hardfail Explained

What the SPF all Mechanism Does

Every SPF record ends with an all mechanism — the catch-all rule defined in RFC 7208 that determines what happens when a sending IP matches none of your authorized senders. The qualifier before all determines the result:

These qualifier semantics are defined in RFC 7208 Section 2.6.7. In practice, the decision comes down to ~all (softfail) versus -all (hardfail). The other two are rarely appropriate: +all disables SPF protection entirely, and ?all provides no actionable signal to receivers.

The short answer: use ~all with DMARC enforcement for most domains. Use -all for domains that never send email.

How Softfail (~all) Works

With ~all, when a message arrives from an IP not listed in your SPF record, the receiving server gets a "SoftFail" result. This signals that the domain owner suspects the message is unauthorized but is not requesting outright rejection.

As described in RFC 7208 Section 8.4, most receiving servers treat SoftFail as a negative signal that contributes to spam scoring but does not directly cause rejection. The message is more likely to land in spam, and is usually not rejected solely for softfail, but receiver policy varies.

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

This record says: "Google and SendGrid are authorized to send for this domain. Messages from other sources are probably not legitimate, but do not reject them outright."

How Hardfail (-all) Works

With -all, when a message arrives from an unlisted IP, the receiving server gets a "Fail" result. This is a definitive statement: the domain owner asserts that no other servers should send email for this domain, and unauthorized messages should be rejected.

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

This record says: "Google and SendGrid are the only authorized senders. Reject anything from other sources."

How Major Providers Handle Each

The textbook distinction is clear. Real-world behavior is more nuanced, and it has shifted significantly since DMARC became widespread.

The key insight: in the DMARC era, the distinction between softfail and hardfail matters less than it used to. When DMARC is configured with p=reject, the DMARC policy overrides the SPF qualifier. A message that fails both SPF and DKIM alignment gets rejected regardless of whether SPF returned SoftFail or Fail.

Why ~all Is Recommended for Most Domains

The conventional wisdom — endorsed by most email deliverability experts and service providers — is to use ~all (softfail) rather than -all (hardfail). Here is why:

1. Email Forwarding Breaks SPF

When a message is forwarded (mailing lists, .forward rules, university alumni forwarding), the forwarding server's IP is not in the original sender's SPF record. With -all, the forwarded message gets a hard fail. With ~all, it gets a soft fail that is less likely to cause outright rejection.

The person being forwarded to is a legitimate recipient — they receive the message through an intermediary you cannot control.

2. DMARC Provides the Enforcement Layer

If you have DMARC configured (and you should — see No DMARC Record Found), the DMARC policy handles enforcement:

• DMARC p=reject rejects unauthenticated messages regardless of SPF qualifier
• DMARC p=quarantine sends unauthenticated messages to spam regardless of SPF qualifier

The combination of ~all in SPF with p=reject in DMARC gives you the best of both worlds: full protection against spoofing via DMARC, while minimizing collateral damage from legitimate forwarded messages where DKIM can save the day.

3. Hardfail Can Cause Unintended Rejections

With -all, some receiving servers reject at the SMTP level before checking DKIM. This means DKIM cannot act as a fallback. With ~all, the message is accepted for further evaluation, giving DKIM a chance to pass and — through DMARC alignment — save the message from rejection.

4. Troubleshooting Is Easier

When adding new sending services or debugging delivery issues, ~all provides a safety margin. A new service that has not been added to SPF yet causes soft failures (messages land in spam) rather than hard rejections (messages bounce). This makes it easier to identify and fix the issue before email is permanently lost.

When -all Makes Sense

Despite the general recommendation for ~all, there are scenarios where -all is appropriate:

Tightly Controlled Environments

If your domain sends email from a small, fixed set of servers with no forwarding, no mailing lists, and no third-party services, -all provides the strongest signal that unauthorized senders should be rejected.

Domains That Do Not Send Email

For domains that never send email (parked domains, redirect-only domains, brand-protection domains), publish an SPF record with no mechanisms and a hardfail:

v=spf1 -all

This tells every receiver: "This domain never sends email. Reject anything claiming to be from it." Pair this with a DMARC record of p=reject for maximum protection.

No DMARC Deployed (Not Recommended)

If you have not deployed DMARC and do not plan to in the near term, -all provides a stronger signal to receiving servers than ~all. However, the better solution is to deploy DMARC rather than rely on SPF hardfail alone.

The Interaction with DMARC

Understanding how SPF qualifiers interact with DMARC is essential:

SPF check → Result (Pass/SoftFail/Fail/PermError) → DMARC alignment check → DMARC policy applied

Per RFC 7489, for DMARC purposes, only SPF Pass counts. Both SoftFail (~all) and Fail (-all) result in DMARC treating SPF as not passing. The distinction between softfail and hardfail is irrelevant to DMARC — what matters is whether SPF passed and whether the domain aligned (see RFC 7489 Section 4.2 on identifier alignment).

This means:

Rows 3 and 4 produce the same DMARC result. The SPF qualifier does not change the DMARC outcome — it only affects how the receiving server handles the message before/outside of DMARC evaluation.

Common Misconceptions

"Hardfail is always more secure"

Not true when DMARC is configured. DMARC p=reject with SPF ~all provides the same spoofing protection as DMARC p=reject with SPF -all. The DMARC policy is the enforcement mechanism, not the SPF qualifier.

"Softfail means my SPF is not working"

SoftFail is a valid, intentional SPF result — not an error. It means "this sender is not authorized, but do not reject outright." It is the correct behavior when you have chosen ~all.

"Google recommends -all"

Google's documentation has varied over the years. Their current guidance recommends ~all for domains using DMARC and -all for domains that need SPF as the sole enforcement mechanism. In practice, Gmail's handling of both is nearly identical when DMARC is present.

"+all is fine because we have DMARC"

No. While DMARC would still enforce policy, +all sends a confusing signal and causes issues with receivers that evaluate SPF independently of DMARC. Never use +all.

Recommendation

For most domains, use this combination:

# SPF with softfail
v=spf1 include:_spf.google.com include:sendgrid.net ~all

# DMARC with enforcement
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Use the mxio SPF Checker to verify your record is valid and within the 10-lookup limit. Use the mxio DMARC Checker to confirm your DMARC policy is correctly published.

For domains that never send email, use -all with no mechanisms:

v=spf1 -all

Prevention and Ongoing Monitoring

Choosing the right all qualifier is a one-time decision, but keeping your SPF record valid is ongoing. Every time you add a sending service, the record changes — and a mistake can push you over the 10-lookup limit or introduce duplicate records.

Set up domain health monitoring to get alerted when your SPF record changes or breaks. For domains with complex SPF setups, mxio's Managed SPF keeps your record optimized automatically — the right all qualifier, flattened lookups, and no manual maintenance.

Related Issues

• SPF PermError: Too Many Lookups — The 10-lookup limit and how to fix it
• Multiple SPF Records — Another common SPF misconfiguration
• Why Is DMARC Failing? — SPF failures contribute to DMARC failures
• Emails Going to Spam — SPF configuration affects deliverability
• No DMARC Record Found — Why DMARC is the enforcement layer you need