The Difference between SPF -all vs ~all

Blog

Mailbox providers now treat SPF -all and ~all mechanisms as “NOT PASS,” unlike before DMARC was used. Here's a quick guide to the SPF all mechanism.

by Yunes Tarada

Reading Time: 4 min
The Difference between SPF -all vs ~all
Table Of Contents−

The SPF all mechanism is an SPF mechanism that exists in your domain’s DNS as a TXT record; it is located at the right end of an SPF record, preceded by “-” or “~”. Let’s take a look at what the difference is between the SPF -all and ~all mechanisms to determine when you should configure them.

Key Takeaways

  1. The SPF -all and ~all mechanisms both indicate “NOT PASS” for SPF authentication but may be treated differently by some email services.
  2. Historically, the SPF Softfail (~all) allowed emails to be delivered even if they failed authentication, while the Hardfail (-all) would reject emails that did not pass.
  3. Modern email services often handle -all and ~all without significant delivery failures, though occasional rejections can occur with -all.
  4. To minimize risk, it is advisable to use the Softfail (~all) mechanism initially while ensuring DMARC is configured and monitoring results.
  5. Implementing DMARC along with proper SPF configurations enhances email security by defining how unauthenticated emails should be handled.

SPF -all vs ~all

Both the SPF -all and SPF ~all mechanisms signify a “NOT PASS” for SPF authentication. In recent times, for a majority of email service providers, there are no differences between the -all and ~all mechanism, and the same result is returned. However, this was not the case a few years ago.

How did the SPF all (Softfail vs Fail) mechanism operate before DMARC?

DMARC was created a long time after SPF had already been in the market as the standard email authentication protocol. At this time the SPF -all softfail mechanism operated in the following way: 

Let’s suppose your SPF record was: 

v=spf1 include:spf.domain.com ~all (where ~all signifies SPF Softfail) 

Your receiver’s email server would have performed a DNS lookup to query the sender’s DNS for their SPF record. If the email’s Return-path domain was not listed in the sender’s record, the receiving server would have returned an SPF “NOT PASS” result but would have delivered the email to the inbox of the receiver. 

Now let’s suppose your SPF record was: 

v=spf1 include:spf.domain.com -all (where -all signifies SPF Fail) 

Your receiver’s email server would have performed a DNS lookup to query the sender’s DNS for their SPF record. If the email’s Return-path domain was not listed in the sender’s record, the receiving server would have returned an SPF “NOT PASS” result, but in this case, the email would have been rejected and not delivered to the inbox of the receiver.

Read more about the history of Sender Policy Framework. 

Simplify SPF with PowerDMARC!

Start 15-day trial Book a demo

How do email service providers handle the SPF -all vs ~all mechanism now?

While you are free to use SPF -all or ~all for most mailbox providers at the current time without having to worry about delivery failures for legitimate emails, there can arise a situation where a server rejects your email in case of the -all attribute. 

Just to be on the safer side, you can avoid using the SPF hard fail -all mechanism while creating your SPF record. This is how you do it:

  • Open the PowerDMARC SPF record generator to start creating a record for free
  • After including the IP addresses and domains or your email senders scroll down to the last section designated to instruct email server’s how strict they should be while verifying your emails
  • Choose the “Soft-fail” option before hitting the “Generate SPF Record” button

What do we recommend? SPF -all or SPF ~all

The issues with email deliverability pertaining to the SPF -all mechanism might occur on very rare occasions. This is not a recurring problem that you will come across often. To ensure you never run into this problem, you can take the following steps:

  • Configure DMARC for your emails, and enable DMARC reporting
  • Set your DMARC policy to monitoring and closely inspect your SPF authentication results to spot any inconsistencies in email deliverability
  • If all is good, you can use the -all mechanism in your SPF record. We recommend using the hard fail attribute since it affirms that you are confident regarding the authenticity of your emails, which can boost your domain’s reputation

If you are currently unsure about using SPF -all, you can follow these steps:

  • Set up an SPF record using the ~all mechanism
  • Configure DMARC for your emails, and enable DMARC reporting
  • Set your DMARC policy to reject

Troubleshooting other SPF errors

While using online tools you may often come across the “No SPF record found” prompt which is a common error state arising from a null result returned when a server looked up your domain’s SPF record. We have covered an article in detail talking about this issue and helping users resolve it. Click on the linked text to know more! 

If you have DMARC in place for your domain on top of SPF, email servers will check your domain’s DMARC policy to establish how you want emails failing authentication to be treated. This policy for DMARC will determine if your emails are delivered, quarantined, or rejected. 

DMARC reject helps protect your domain against a variety of impersonation attacks like spoofing, phishing, and ransomware.

Latest posts by Yunes Tarada (see all)
Types of Social Engineering Attacks in 2022Social Engineering AttacksCyber Resilience and DMARCCyber Resilience and DMARC