Microsoft's new regulations are officially live as of May 5th 2025.  Check if your domain is protected

SPF Softfail (~all) vs. Hardfail (-all): Why Softfail is the Smarter Choice for Email Security

Published on
August 29, 2025

When you publish an SPF (Sender Policy Framework) record, there’s one little detail that often sparks debate: should the record end with ~all (softfail) or -all (hardfail)?

Hardfail sounds like the more secure option — and for unused domains, it often is. But for domains that actively send email, softfail (~all) is almost always the better long-term choice. When paired with DMARC and DKIM, it provides equal protection against spoofing, without risking lost messages or deliverability headaches.

This article explains:

  • What ~all and -all actually mean
  • How mail servers interpret each
  • Why softfail is the safer option for active sending domains
  • How DMARC makes hardfail unnecessary for security
  • How to implement softfail + DMARC in a way that’s both safe and future-proof

What ~all and -all Mean

In SPF, the all mechanism tells receiving servers what to do with messages from senders that aren’t listed in your record.

SPF “~all” (Softfail) vs “-all” (Hardfail)
Mechanism Meaning Typical Behavior
~all (Softfail) “This sender is probably not authorized, but don’t block it outright.” Message is accepted but marked as suspicious; often routed to spam.
-all (Hardfail) “This sender is not authorized. Reject it.” Message is rejected or bounced during delivery.

How Mail Servers Handle SPF Results

SPF doesn’t decide the fate of a message — mail servers do, based on SPF’s signal. According to RFC 7208 [2]:

  • A hardfail (-all) is a strong indicator the sender isn’t authorized. Most mail servers will reject the message outright.
  • A softfail (~all) signals suspicion without demanding rejection. Servers will accept the message but may mark it as spam or subject it to additional checks. Rejection based solely on a softfail is discouraged by the standard.

Think of it as a traffic signal:

  • -all = red light — stop the message.
  • ~all = yellow light — proceed with caution.

The Forwarding Problem

Forwarding is SPF’s Achilles heel. Here’s why:

  • When your email is forwarded, the forwarding server becomes the new sender.
  • That forwarding server almost never appears in your SPF record.
  • With -all, forwarded emails often fail SPF and get rejected outright.
  • With ~all, those same emails are accepted but flagged, giving DKIM and DMARC a chance to authenticate them.

DMARC Levels the Playing Field

DMARC (Domain-based Message Authentication, Reporting, and Conformance) changes the calculus entirely. It uses SPF and DKIM results to decide whether a message is authenticated. Here’s what matters:

  • If either SPF or DKIM passes and aligns, the message passes DMARC.
  • If both fail, DMARC applies your policy (none, quarantine, or reject).
  • DMARC doesn’t distinguish between SPF softfail or hardfail — both are simply treated as “fail.”

This means:

  • Spoofed emails are still blocked or quarantined under DMARC, regardless of whether SPF fails in a soft or hard manner.
  • Legitimate forwarded messages have a chance to pass via DKIM, even if SPF fails.

Why Softfail Is the Better Long-Term Choice

For active sending domains, softfail is the best balance of security and deliverability:

  • No loss of security with DMARC enforcement
  • DMARC treats softfail and hardfail equally when enforcing your policy. Spoofed messages will still be blocked or quarantined.
  • Fewer false positives
  • New mail services, relays, or unlisted IPs won’t cause your legitimate messages to bounce.
  • Better handling of forwarding
  • Forwarded messages won’t be dropped prematurely, allowing DKIM or other checks to validate them.
  • Aligned with modern best practices
  • Industry guidance and RFC 7489 [1] recommend using ~all for domains that send email, and reserving -all for non-sending domains.

When Hardfail Makes Sense

The only clear scenario where -all is recommended is for domains that don’t send any email.

For example:

  • example.net is only used for a website and has no mailboxes.
  • Setting -all plus a DMARC p=reject policy blocks all email from that domain, eliminating spoofing risk entirely.

How to Implement Softfail + DMARC Safely

  1. Publish SPF with ~all
  2. v=spf1 include:_spf.sendingtool1.com include:_spf.sendingtool2.com ~all
  3. Enable DKIM signing for all legitimate senders.
  4. Add a DMARC record starting with p=none for monitoring.
  5. Monitor reports to ensure all valid mail sources are covered.
  6. Gradually enforce DMARC — move from p=nonep=quarantinep=reject.
  7. Keep your records updated as new services or IPs are added.

Key Takeaways

  • SPF softfail (~all) + DMARC enforcement = strong security with better deliverability.
  • Hardfail (-all) should be used only for domains that don’t send email.
  • DMARC and DKIM are the real backbone of modern email authentication — SPF is a supporting signal, not the sole gatekeeper.

By choosing softfail and layering it with DMARC and DKIM, you protect your brand from spoofing and ensure that your legitimate emails continue to flow to inboxes.

Published on
August 29, 2025
Author
Samuel Chenard - Founder & CEO
Email Performance Score
Improve results with AI- no technical skills required

SPF Softfail (~all) vs. Hardfail (-all): Why Softfail is the Smarter Choice for Email Security

Published on
August 29, 2025
Contributors
No items found.
Subscribe to our newsletter
Read about our privacy policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

When you publish an SPF (Sender Policy Framework) record, there’s one little detail that often sparks debate: should the record end with ~all (softfail) or -all (hardfail)?

Hardfail sounds like the more secure option — and for unused domains, it often is. But for domains that actively send email, softfail (~all) is almost always the better long-term choice. When paired with DMARC and DKIM, it provides equal protection against spoofing, without risking lost messages or deliverability headaches.

This article explains:

  • What ~all and -all actually mean
  • How mail servers interpret each
  • Why softfail is the safer option for active sending domains
  • How DMARC makes hardfail unnecessary for security
  • How to implement softfail + DMARC in a way that’s both safe and future-proof

What ~all and -all Mean

In SPF, the all mechanism tells receiving servers what to do with messages from senders that aren’t listed in your record.

SPF “~all” (Softfail) vs “-all” (Hardfail)
Mechanism Meaning Typical Behavior
~all (Softfail) “This sender is probably not authorized, but don’t block it outright.” Message is accepted but marked as suspicious; often routed to spam.
-all (Hardfail) “This sender is not authorized. Reject it.” Message is rejected or bounced during delivery.

How Mail Servers Handle SPF Results

SPF doesn’t decide the fate of a message — mail servers do, based on SPF’s signal. According to RFC 7208 [2]:

  • A hardfail (-all) is a strong indicator the sender isn’t authorized. Most mail servers will reject the message outright.
  • A softfail (~all) signals suspicion without demanding rejection. Servers will accept the message but may mark it as spam or subject it to additional checks. Rejection based solely on a softfail is discouraged by the standard.

Think of it as a traffic signal:

  • -all = red light — stop the message.
  • ~all = yellow light — proceed with caution.

The Forwarding Problem

Forwarding is SPF’s Achilles heel. Here’s why:

  • When your email is forwarded, the forwarding server becomes the new sender.
  • That forwarding server almost never appears in your SPF record.
  • With -all, forwarded emails often fail SPF and get rejected outright.
  • With ~all, those same emails are accepted but flagged, giving DKIM and DMARC a chance to authenticate them.

DMARC Levels the Playing Field

DMARC (Domain-based Message Authentication, Reporting, and Conformance) changes the calculus entirely. It uses SPF and DKIM results to decide whether a message is authenticated. Here’s what matters:

  • If either SPF or DKIM passes and aligns, the message passes DMARC.
  • If both fail, DMARC applies your policy (none, quarantine, or reject).
  • DMARC doesn’t distinguish between SPF softfail or hardfail — both are simply treated as “fail.”

This means:

  • Spoofed emails are still blocked or quarantined under DMARC, regardless of whether SPF fails in a soft or hard manner.
  • Legitimate forwarded messages have a chance to pass via DKIM, even if SPF fails.

Why Softfail Is the Better Long-Term Choice

For active sending domains, softfail is the best balance of security and deliverability:

  • No loss of security with DMARC enforcement
  • DMARC treats softfail and hardfail equally when enforcing your policy. Spoofed messages will still be blocked or quarantined.
  • Fewer false positives
  • New mail services, relays, or unlisted IPs won’t cause your legitimate messages to bounce.
  • Better handling of forwarding
  • Forwarded messages won’t be dropped prematurely, allowing DKIM or other checks to validate them.
  • Aligned with modern best practices
  • Industry guidance and RFC 7489 [1] recommend using ~all for domains that send email, and reserving -all for non-sending domains.

When Hardfail Makes Sense

The only clear scenario where -all is recommended is for domains that don’t send any email.

For example:

  • example.net is only used for a website and has no mailboxes.
  • Setting -all plus a DMARC p=reject policy blocks all email from that domain, eliminating spoofing risk entirely.

How to Implement Softfail + DMARC Safely

  1. Publish SPF with ~all
  2. v=spf1 include:_spf.sendingtool1.com include:_spf.sendingtool2.com ~all
  3. Enable DKIM signing for all legitimate senders.
  4. Add a DMARC record starting with p=none for monitoring.
  5. Monitor reports to ensure all valid mail sources are covered.
  6. Gradually enforce DMARC — move from p=nonep=quarantinep=reject.
  7. Keep your records updated as new services or IPs are added.

Key Takeaways

  • SPF softfail (~all) + DMARC enforcement = strong security with better deliverability.
  • Hardfail (-all) should be used only for domains that don’t send email.
  • DMARC and DKIM are the real backbone of modern email authentication — SPF is a supporting signal, not the sole gatekeeper.

By choosing softfail and layering it with DMARC and DKIM, you protect your brand from spoofing and ensure that your legitimate emails continue to flow to inboxes.