What are the advantages and disadvantages of using Fail vs. a SoftFail in my SPF record?

What I found on the topic

Back in 2007, knowledgeable-seeming folks seem to have said SoftFail was just for testing and encouraged changing it to reject once you have everything setup properly (here and here)

This forum post calls SoftFail "wrongly configured", but then says that Google uses it. I trust Google for best practices more than a random forum poster! I checked and indeed, Gmail uses ~all (a SoftFail) in their SPF record.

On the sender end of things, email deliverability experts seem to encourage using SoftFail:

Fail "is more aggressive [than SoftFail] and is known to create more issues than it solves (we don’t recommend it)."

Postmark SPF Guide

That's rather vague.

"I generally recommend publishing ~all records for my clients. There’s not a huge benefit to publishing -all and sometimes mail gets forwarded around. The one time I recommend a -all record is when a domain is getting forged into spam. Domain forgery can cause a lot of bounces. The amount of bounces can be bad enough to take down a mail server, particularly those with a small userbase. Many ISPs will check SPF before sending back a bounce and so a -all record can decrease the amount of blowback the domain owner has to deal with."

—Email deliverability consultants Word to the Wise

Yet how will a webmaster know if there is a substantial amount of domain forgery going on? Isn't a best practice to prepare for the worst and anticipate forgery in advance?

On the receiving end, Terry Zink, who works in enterprise spam filtering, offers a strong case for hard Fail to prevent phishing emails from going through, and says most people use SoftFail because organizations are more afraid of emails being lost than about forged emails. What is the likelihood that a forged phishing email which SPF SoftFails actually gets to someone's inbox?

  • 5
    Don't trust Google Mail for best practices. SPF is one of the things that they get very, very wrong, both in their own record and in validating others' records. And ~all is functionally the same as not having an SPF record at all. Oct 3, 2018 at 3:46
  • Related: serverfault.com/q/355511 Oct 3, 2018 at 15:11
  • 2
    @MichaelHampton, that might have been the intention when SPF was first created, but it's not the reality now. The qualifier (~ or -) was supposed to declare a kind of policy on how to deal with failures, but this caused unintended delivery errors and failed to address the issue of spoofing. DMARC is now the recommended way to declare policy, and for that reason ~all and -all are practically equivalent. For those servers still configured to discard failed -all messages immediately (without DMARC) you'll encounter the same problems as always, which is why many people recommend ~all.
    – Kal
    Feb 11, 2020 at 2:01

2 Answers 2


Sondra, you already found a related question, but the highest scoring answer doesn't do justice to your questions, in my opinion.

Let me start with your last question: What is the likelihood that a forged phishing email which SPF SoftFails actually gets to someone's inbox? Huge! Combined with DMARC quarantine/reject policy and the receiving mailbox on Office 365, Outlook.com, Gmail, Yahoo or other major hoster, very unlikely.

Your first question: What are the advantages of a Fail over a Soft Fail SPF record. As mentioned in your own research, a disadvantage will be that forwarded emails will be rejected unless the bounce address (return-path) is rewritten by the forwarder. An advantage is the domain being better protected against spoofing, but only for the simplest of attempts.

As mentioned above, the caveat with SPF is that it checked against SMTP envelope sender, saved in the message header field Return-Path. An actual recipient will have no knowledge of this field, because most email clients will only present them with an other field, the header From. For example: I send an email with a header From: [email protected], but I use [email protected] as the envelope sender. Even though microsoft.com publishes a Fail SPF policy, it will not fail SPF because example.com does not publish an SPF record. The recipient will just see an email from [email protected].

This is where DMARC comes in. DMARC requires authentication alignment with the domain used in the From header, either for SPF or DKIM. Meaning the domain used in the envelope sender (Return-Path) and the header From: should share an organizational domain. DMARC only cares about PASS results for underlying authentication mechanisms (SPF or DKIM), so, for SPF in that respect ~all and -all are treated exactly the same.

Terry Zink has published multiple articles on DMARC, one of which: Enhanced email protection with DKIM and DMARC in Office 365

There is a lot one could learn about SPF, DKIM and DMARC, which is beyond the scope of this answer. DMARC is not easy to implement nor flawless, but it does protect your domain against spoofing, much better than only SPF. Also, all depends on the receiving party and how they deal with SPF and DMARC (if at all).

  • "An advantage is the domain being better protected against spoofing, but only for the simplest of attempts." Could you elaborate whate are more sophisticated attempts that SPF does not protect against?
    – Learner
    Nov 26, 2018 at 13:51
  • 1
    @Learner As described, SPF will be checked on the email domain used in the return-path. The recipient will generally see the Header From email address, which doesn't have to be in the same domain.
    – Reinto
    Nov 26, 2018 at 15:12
  • 1
    A pretty good answer. Could be improved I think by adding that DMARC considers both ~all and -all to be equivalent (i.e. an SPF fail) since the OP was asking about the pros and cons of each. Also, you can probably delete the first line, because 'Sondra' is actually the OP. :-)
    – Kal
    Feb 11, 2020 at 3:16
  • 1
    Agreed, @Kal. I've updated the answer to clarify the (lack of) effect of SPF fail and softfail on DMARC results.
    – Reinto
    Feb 12, 2020 at 9:08

As Email Marketing continues to grow it's important to ensure all of your emails are properly authenticated with SPF, DKIM, DMARC, and eventually BIMI.

You should start by auditing all of the tools and applications that you use to send emails from your domain. Then be sure to setup SPF and DKIM for each tool or application so its properly authenticated.

Lastly you can use a DMARC Analyzer tool to setup DMARC with a none policy and monitor your aggregate reports for a few weeks. DMARC will help you ensure that all of your emails are properly authenticated.

After you've monitor your reports for a few weeks and have made sure that only authenticated emails are being sent you can begin to rollout or enforce a dmarc policy.

Now back to your original question I think during the DMARC integration process you can use a ~all policy but after you've audited your entire infrastructure and set up SPF & DKIM you could use a more strict -all policy within your SPF record.

If you want to learn more about SPF Failures I'd suggest reading SPF Soft Fail – Everything about SPF Failures.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .