SPF Authentication: SPF-all vs ~all

What is SPF? Sender Policy Framework (SPF) lets the admin specify what IP addresses are allowed to send emails on a domain’s behalf. This authorization is published as a TXT record in the DNS Provider (Cloudflare, GoDaddy, etc.). Note that SPF checks against the 5321.MailFrom address (also known as Return-Path, Envelope From, or Bounce address) to authorize sending IP addresses. The recipient’s mail server, if it adheres to the sender’s domain SPF policy, should act in accordance with the published SPF policy.

There’s been a historical dispute related to using SPF hard fail or soft fail since the inception of Sender Policy Framework in 2004.

In this article, we’ll discuss why you should use SPF softfail vs hardfail (-all vs ~all)?

SPF Record: what does it look like?

SPF TXT record starts with the SPF version indicator followed by all the ‘whitelisted’ IP addresses that are authorized to send emails on a domain’s behalf, ending with an all tag. Here are the possible ones:

1. -all (Fail): email from servers / IP addresses, not listed in the SPF record, should be rejected.
2. ~all (SoftFail): emails from servers / IP addresses, not listed in the SPF record, should be accepted but marked 
3. +all (Pass): any servers can send emails on your domain’s behalf. We highly recommend not to use this option. 
4. ?all (Neutral): Interpreted as None / No policy. We highly recommend not to use this option.

The tags above indicate what policy should be applied to email when MBPs (Mailbox Providers like Google, Microsoft, Yahoo!, etc.) detect that mail was sent from servers / IP addresses not listed in the SPF record. Using SPF hard fail or soft fail are the two more accepted methods. Still, the preference falls on the ~all.

Now that you know you shouldn’t be using +all and ?all, let’s review an example before we touch upon the SPF SoftFail vs HardFail issue. (Use our free SPF testing tool to test your SPF records.)

SPF Record Example:

v=spf1 ip4:172.16.254.1 ip4:213.22.138.0/24 ip6:2001:db8:0:1234:0:567:8:1 include:_spf.google.com -all

1. v=spf1: SPF record should always start with v=spf1 version number.
2. ip4 and ip6 mechanisms: Lists the single IP address (e.g 172.16.254.1 and 2001:db8:0:1234:0:567:8:1) or IP subnets (e.g. ip4:213.22.138.0/24) that are authorized to send emails on a domain’s behalf. Note that IPv4 addresses should be prefixed as “ip4”, and IPv6 as “ip6” tags.
3. “include” mechanism: Used to authorize third-party services that are used to send emails on your domain’s behalf. In this example, the “_spf.google.com” authorizes Google Workspace (formerly G Suite) to send emails on behalf of your domain.
4. “all” mechanism: In this example, the “-all” (Fail) tag is used.

Now, the example uses SPF record hardfail vs softfail, which will discard all the emails that fail the test, including the legitimate ones.

SPF -all vs ~all: what should I use? 

Before DMARC adoption (in 2012), SPF alone played a major role, despite its limitations, in fighting against Return-Path or MailFrom email spoofing attempts. MBPs applied rules based on the admins’ expressed SPF record policies (~all or -all). Thus, this caused major issues with blocking legitimate emails due to SPF configuration errors, which led the majority and well-known MBPs to use both SoftFail (~all) and Fail (-all) as accept but mark method.

There are a few SPF fail vs. soft-fail pros and cons. Let‘s dive into the 3 main reasons why we at EasyDMARC advise our users to publish SPF records with ~all.

1. Since DMARC adoption, MBPs use domains’ DMARC policies (p=quarantine or p=reject) to apply rules to the failed emails. SPF record softfail vs hardfail initially meant that the email shouldn’t pass. However, there’s a slight difference. SPF ~all means “Not Passed” while -all means “SPF Failed and the email should be rejected.”
2. Using SPF ~all can make the debugging process of DMARC Aggregate reports easier (Identifying Return-Path addresses)
3. Once in a while, you may come across some not-well-known MBPs who still treat SPF “Fail” and “SoftFail” as it was originally intended and produce various false-positive results with bouncing legitimate emails. This can be avoided by using SPF softfail vs hardfail.

Next Steps

Optimizing SPF records can be pretty challenging, so our guide on SPF optimization.

Also, check our SPF Raw Checker to validate your SPF Record prior to implementing it in your DNS.

To check if you have your SPF record properly setup, inspect your domain with our free SPF Record check tool. To create a new SPF record, use our SPF Generator tool.

Also, read our ultimate guide about SPF to improve email delivery.