SPF softfail vs hardfail: which should you use?

For active sending domains, use softfail (~all) and enforce your policy through DMARC. For domains that never send email, use hardfail (-all). The security outcome is the same either way when DMARC is at p=reject, but hardfail can block legitimate email before DMARC ever gets a chance to evaluate it.

Sender Policy Framework (SPF) gives domain administrators two ways to handle unauthorized senders: draw a hard line, or draw a softer one. Choosing between them sounds simple until you factor in DMARC, email forwarding, and what receiving servers actually do with each result in practice.

A SPF hardfail (-all) tells receiving servers that a sender is explicitly not authorized. A SPF softfail (~all) says the sender is probably not authorized but leaves more room for the receiving server to decide what to do. In the pre-DMARC era, that distinction mattered a great deal.

Today, DMARC treats both results identically as SPF failed.

This guide covers what hardfail and softfail mean on their own, how DMARC changes the way each is interpreted, and which one you should be using.

Softfail vs. Hardfail: what’s the difference?

SPF uses a TXT record in a domain’s DNS settings to authorize certain mail servers to send from that domain. Let’s look at the syntax and semantic differences between fail types.

We can see the SPF policy of an actual domain by performing a DNS lookup and checking the pertinent TXT record. Let’s take a peek at a real SPF record, using the nslookup command-line tool:

PS C:> nslookup -type=TXT google.com | grep spf
google.com    text = "v=spf1 include:_spf.google.com ~all"

To see an in-depth explanation of the syntax of an SPF record, check out our dedicated article on SPF record syntax. For the purposes of the current guide, we’re only concerned with the last part: ~all. The tilde means that Google prefers recipients to softfail noncompliant mail. If the tilde had instead been a dash, that would indicate hardfail. 

For a full breakdown of the ~all and -all syntax and all four SPF qualifiers, see our guide on SPF -all vs ~all.

What is SPF hardfail?

SPF hardfail is when a domain’s SPF record explicitly states that an email is not authorized. In the DNS record, hardfail is represented by a dash before all:

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

The -all at the end tells every receiving mail server: any email that comes from a source not listed in this record is unauthorized, and you should reject it.

According to RFC 7208, a hardfail result is “an explicit statement that the client is not authorized to use the domain in the given identity.” There’s no ambiguity. The policy is drawing a hard line.

What happens when a server receives SPF hardfail

In practice, behavior varies. The RFC suggests that a hardfail should result in a 550 5.7.1 SMTP rejection, meaning the email never reaches the recipient’s inbox.

Many servers do follow this, but not all.

Some may still deliver the message and add an authentication warning to the headers. Others route it to spam instead of rejecting outright.

The inconsistency is part of why DMARC was created. SPF’s failure modes were always advisory rather than enforceable, and individual servers implemented them however they saw fit.

When SPF hardfail is appropriate

Hardfail makes the most sense for domains that don’t send email at all. If you own a domain purely for a website, a holding company, or a legacy asset, and no email is ever legitimately sent from it, hardfail closes the door on anyone trying to spoof it.

For a non-sending domain, the record is as simple as:

v=spf1 -all

This tells the world: nothing from this domain is authorized, ever.

What is SPF softfail?

SPF softfail is when a domain’s SPF record signals that an email is probably not authorized, without committing to an outright rejection. In the DNS record, softfail is represented by a tilde before all:

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

The ~all tells receiving servers: any email from an unlisted source is suspicious, but use your own judgment about what to do with it.

RFC 7208 describes softfail as “a weak statement by the publishing Administrative Management Domain (ADMD) that the host is probably not authorized. It has not published a stronger, more definitive policy that results in a fail.”

What happens when a server receives SPF softfail

Most receiving servers treat softfail as a cue to deliver the message to spam or flag it with a warning header, rather than blocking it outright. The email arrives, but with reduced trust. What actually happens depends on the receiving server’s configuration, the sender’s reputation, and whether DMARC is involved.

Without DMARC, softfail results in genuinely inconsistent outcomes across different mail providers. With DMARC, the picture becomes much cleaner.

Why softfail is the right default for active senders

Softfail gives you a safety net. If you accidentally omit a legitimate sending service from your SPF record, those emails will still reach recipients, just potentially in spam. That’s a recoverable situation. You’ll see it in DMARC reports, fix the record, and move on.

Hardfail offers no such recovery. A misconfigured hardfail means legitimate email gets permanently blocked, silently, with no visibility unless you’re actively monitoring for bounces.

How DMARC changes everything

Understanding hardfail and softfail in isolation only gets you so far. DMARC is where the real behavior change happens, and it fundamentally shifts the significance of the distinction between the two.

DMARC doesn’t care whether your SPF record uses -all or ~all. Both outcomes are treated the same way: SPF failed. What DMARC does care about is what happens next, and that’s determined entirely by your DMARC policy (p=none, p=quarantine, or p=reject), not by your SPF qualifier.

This means:

• Softfail (~all) + DMARC at p=reject = unauthorized email gets rejected
• Hardfail (-all) + DMARC at p=reject = unauthorized email gets rejected

The security outcome is identical. The difference is in what happens to legitimate email when something goes wrong.

Softfail vs hardfail: which should you use?

If your domain sends email

Use softfail (~all), and pair it with DMARC at p=quarantine or p=reject.

Softfail + DMARC p=reject delivers the same security outcome as hardfail without the deliverability risk. DMARC becomes the enforcement layer, and SPF feeds it authentication results. The SPF qualifier itself stops being the decision-maker.

This is the current recommendation from M3AAWG (the Messaging, Malware and Mobile Anti-Abuse Working Group), and it reflects where the industry has landed after years of real-world experience with both approaches.

If your domain does not send email

Use hardfail (-all).

For parked domains, legacy domains, or any domain that will never legitimately send email, hardfail makes sense. There’s no risk of blocking legitimate mail because there isn’t any. The hard line is appropriate.

A note on Microsoft 365

Microsoft’s documentation for 365 recommends -all in some configurations, specifically when DKIM isn’t configured alongside DMARC. Their reasoning: without DKIM, there’s no alternative pass path for DMARC, so a softer SPF signal leaves a gap.

If you’re on Microsoft 365 without DKIM configured, their guidance is worth following. But the better long-term answer is to configure DKIM — which removes the argument for hardfail and makes softfail the right call.

Summary

Best practices and use cases

Hopefully we’ve helped you cultivate at least an intuitive understanding of what hardfail and softfail mean in SPF and knowledge of the syntactical and semantic difference between the two. With that domain-specific knowledge in mind, we can solidify the abstract, conceptual understanding of SPF’s support for hardfails and softfails into practical knowledge about when and why a domain admin should use one or the other.

Below we outline some basic best practices for SPF, with particular care for the relevance of the distinction between both failure modes. Read more to build your intuition of which should be used when, and why.

Configure domains that don’t send email

What if you, as a webmaster, own a website with a domain that won’t send any email whatsoever? Even then, you’ll still likely want to prevent other people from fraudulently sending mail from your domain without your authorization. And that’s where SPF comes in: it allows you to create a policy that completely hardfails all mail sent from your domain.

Such a policy is simple to create and would look like this: v=spf1 -all.

Disallowing all outgoing mail for a domain using SPF is trivial. However, as we mentioned earlier, the presence of DKIM and DMARC policies alongside SPF might change behavior in big ways. Thus, it’s important to also ensure that DMARC is not undermining SPF. 

If you wish to learn more about how DMARC works, you may benefit from checking out our article dedicated specifically to the topic: What is DMARC.

Stick with Softfail

Automating forwarding of mail will cause SPF to fail if the forwarder is not listed in the SPF policy as an approved sender for the domain. For this reason, it’s recommended to prefer softfail instead of hardfail.

Integrate DMARC

Even when applying the stricter hardfail option, SPF has serious inadequacies if used by itself. Among its most grave weaknesses is that SPF leaves email vulnerable to spoofed “from” addresses. SPF uses the domain shown in a message’s Return-Path field for authentication, which is different from the “From:” address that the human recipient of an email will see.

To learn more about the strengths and weaknesses of SPF, you can peruse the “SPF limitations” section of our article dedicated to SPF more generally: What is SPF?

DKIM and DMARC are email security protocols that exist to complement SPF and make up for some of its inadequacies. If you’re interested in SPF, it’s probably because you are really worried about preventing fraudulent senders from abusing your domain. Learn about DKIM and DMARC via our guide: DMARC vs DKIM.

Verify your policy

It’s easy to misconfigure an SPF policy. When you add a DNS record, you likely won’t receive any kind of alert from the nameserver letting you know if you’ve provided a policy that makes no sense at all.

Luckily for you, free tools exist online that allow you to analyze an SPF policy to make sure it is syntactically sound and actually does what you think it’s supposed to do. A broad variety of such tools can be found easily on any search engine, but Valimail’s Domain Checker is a good starting point.

Overall, it’s an integral part of verifying or debugging an SPF policy.

Example output of Valimail’s Domain Checker using valimail.com to test with

Start Your Journey to DMARC Enforcement with Free Visibility

Get Free Visibility

Minimal resource requirement with only a single one time DNS change needed

DMARC Enforcement guarantee and 97.8%+ success rate

100% Automated service discovery and 1-click validation

Get your SPF right from the start

The softfail vs. hardfail decision matters, but it’s not where most organizations should focus their energy. The bigger priority is getting DMARC to enforcement.

That’s what turns SPF from an advisory signal into an active defense.

Not sure where your domain stands? Run a free domain check with Valimail Monitor to see your SPF, DKIM, and DMARC status in seconds. No signup required.

Frequently asked questions

What does SPF hardfail mean?

SPF hardfail means a domain’s SPF record has explicitly declared that an email from an unlisted source is not authorized. It’s represented by -all in the SPF record syntax. Receiving servers that honor the hardfail signal will reject the email outright, though actual behavior varies by server.

What does SPF softfail mean?

SPF softfail means the SPF record has signaled that an email from an unlisted source is probably not authorized, but hasn’t committed to outright rejection. It’s represented by ~all. Servers typically deliver softfail emails to spam or flag them with a warning header rather than blocking them.

Does DMARC treat hardfail and softfail differently?

No. DMARC treats both as “SPF failed” and applies your DMARC policy accordingly. Whether your SPF record uses -all or ~all has no effect on how DMARC handles the failure. Your DMARC policy (p=none, p=quarantine, or p=reject) is what determines the outcome.

Can SPF hardfail block legitimate email?

Yes, and this is the main reason most email security experts recommend softfail for active senders. Some mail servers run SPF checks before they process DKIM or DMARC. If hardfail causes an early rejection at that stage, the email is blocked before the server checks whether DKIM would have passed. Softfail avoids this by leaving room for DKIM and DMARC to complete their evaluation.

What happens if I have no SPF record at all?

Without an SPF record, receiving servers have no policy to evaluate. The SPF result comes back as “none,” which DMARC treats as a failure. Your domain is also more vulnerable to spoofing since there’s nothing preventing anyone from sending email in your name. Publishing even a basic SPF record is a minimum baseline.