SPF exists in your domain’s DNS as a TXT record with a bunch of mechanisms and modifiers that stand for specific instructions. The SPF all mechanism is present 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.
SPF -all vs ~all
Both the SPF -all and ~all mechanisms signify “NOT PASS” for SPF authentication. In recent times, for a majority of email service providers, there is no difference 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 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.
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.