Sender Policy Framework or SPF improves the sender’s reputation and email delivery in addition to keeping phishing and spoofing attacks at bay. However, the intricacies involved in creating and managing an SPF record can cause many instances of SPF failures. These issues should be identified, addressed, and fixed at the earliest to avoid downtime and vulnerability to attacks.
So, let’s quickly understand how SPF authentication works and then move to learning how to fix SPF failure.
How Does SPF Authentication Work?
SPF authentication works on the basis of an SPF record that is published on the domain’s DNS (Domain Name System). The SPF record includes all the IP addresses allowed to send emails on behalf of the domain or business owner.
The sending MTA confirms if the connecting host’s IP address or sending source is mentioned in the corresponding SPF record. If it’s mentioned, the authentication result’s status is ‘pass’; otherwise, it’s ‘fail.’
Please note that ‘SPF fail’ and ‘SPF failure’ are not the same. SPF fail means the sending source is not mentioned in the published SPF record, whereas SPF failure occurs due to technical errors. It’s important to run your SPF TXT record through an SPF lookup tool that highlights all the existing errors hindering the SPF authentication process or invalidating the record itself.
Learning to Fix SPF Failure in Different Cases
Here are the different cases causing an SPF failure and ways to resolve them-
Case 1: SPF None Result
The SPF none result returns in two cases; first, when a recipient’s mail server is not able to retrieve the domain name in the DNS, and second, when there is no SPF record published in the sender’s DNS. It’s suggested to create SPF record instead of fixing the previous one to avoid this situation.
Case 2: SPF Neutral Result
A valid SPF record ends with either -all or ~all mechanism. Some domain owners use the ?all mechanism, which allows all internet users to send email messages on behalf of their organization and using their domain name. So, in this situation, the receiving MTA will always return a neutral result, irrespective of the SPF authentication checks.
Using the +all or ?all mechanism is highly discouraged as it gives threat actors the perfect opportunity to exploit your domain name and send phishing emails by posing as someone from your organization. So, even illegitimate email messages will land in inboxes instead of spam folders.
Case 3: SPF Softfail Result
Affixing ~all at the end of your SPF record indicates a softfail, which means recipients’ mail servers will place suspicious messages in the spam folders. By suspicious messages, we mean emails sent from IP addresses that are not listed in the sender domain’s SPF record.
Here’s an example of an SPF record with a softfail
v=spf1 include:spf.google.com ~allCase 4: SPF Hardfail Result
SPF records having the -all mechanism at the end indicate a hardfail, which directs receiving MTAs to reject the entry of emails sent from unauthorized IP addresses. This mechanism offers the highest level of protection from deploying SPF email authentication protocol as potentially phishing messages don’t show up in the inboxes.
Here’s an example of an SPF record with a hardtail
v=spf1 include:spf.google.com -allCase 5: SPF TempError
SPF authentication failures frequently occur for a common and generally harmless reason known as SPF TempError, a temporary issue arising from DNS errors. This may involve a DNS timeout during the SPF authentication check conducted by the receiving MTA. As implied by its name, SPF TempError typically produces a temporary setback, returning as a 4xx status code, leading to a momentary SPF failure. Nevertheless, reattempting the process later often results in a successful SPF pass outcome.
Case 6: SPF Permerror
SPF permerror is short for permanent SPF errors that get triggered when your SPF record has one or more of the following issues-
- Multiple SPF records found for a domain.
- Missing IP addresses from the SPF record.
- Exceeded the SPF lookup limit of 10.
- Exceeded the void lookup limit of 2.
- Exceeded the limit of 255 characters.
- Wrong use of SPF syntax (mechanisms, modifiers, and qualifiers)
When an MTA conducts an SPF check on an email, it either queries the DNS or performs a DNS lookup to verify the legitimacy of the email source. In the context of SPF, it is essential to note that you are permitted a maximum of 10 DNS lookups. Surpassing this limit will result in SPF failure, leading to a PermError. Employing SPF flattening can be a useful strategy in managing and staying within this lookup limit.
Final Words
Image sourced from cybessential.com.au
SPF, DKIM, and DMARC work together to protect email-sending domains of targeted organizations by highlighting messages sent by unauthorized senders. -all and ~all mechanisms instruct the email server of a recipient to place an illegitimate message in the spam folder or reject its entry. However, an SPF validation error or SPF failure disrupts this process, and messages sent from unauthorized sources also get placed in the primary inboxes. Moreover, unfixed SPF failure cases cause email deliverability issues for domain owners.
