If your email messages are landing your recipients' spam folders, the likeliest cause is a missing or misconfigured SPF record in the sending domain.
Modern email providers might even completely reject your message with an error, as shown in the following screenshot:
This problem is most common in email messages generated by websites or CMS software. If you are facing such a problem, this guide can help you.
Sender Policy Framework (SPF)
The Sender Policy Framework (SPF) is a standard that is used as a policy by publishing a TXT record in the DNS of a domain. The SPF record contains the list of IP addresses, domain names, and third-party services that are authorized to send email messages on behalf of your domain.
To prevent recipient email servers from rejecting or treating the email messages sent from your domain as spam, it is highly recommended to publish an SPF record in your domain's DNS. The recipient email servers could then query this record to verify whether the email message was actually sent by a legitimate (authorized) source IP address or domain.
SPF record syntax and examples
The syntax of an SPF record is fairly simple, as shown below:
v=spf1 <authorized_IP_addresses_or_domains> <enforcement_rule>
The following screenshot shows an example of an SPF record:
- The value of every SPF record starts with v=spf1, which indicates that it is an SPF (version 1) record.
- The next section defines the authorized IP addresses (or IP address block) and domain names. The multiple values are separated by a single white space. For example, if you're using Microsoft 365 for business emails and MailChimp for sending transactional emails from a website, you could use multiple include mechanisms. Your SPF record will look like this:
v=spf1 include:spf.protection.outlook.com include:spf.mandrillapp.com -all
The last part of the SPF record is the enforcement policy, which could have either of the following values:
- ?all—Use this at the end to set the SPF policy to neutral, which means the SPF record doesn't explicitly state that the IP address is authorized or not. This setting is rarely used.
- ~all—Use this at the end to indicate that all other servers, except those specified, are not authorized. The email messages are marked with soft-fail in the envelope but are likely to be accepted by the recipient server. This is a temporary setting that is recommended during a transitioning period, such as during an email migration process.
- -all—Use this at the end to indicate that all other servers are not authorized. The email messages are marked with hard-fail in the envelope and are likely to be rejected by the recipient server (depending on the policy). This is a recommended setting for production domains.
- +all—Use this at the end to indicate that all other servers are also authorized to send emails on the domain's behalf. This setting makes the SPF record useless and should never be used.
The following table shows the SPF records of some popular email service providers:
|Email Provider||SPF Value|
|Microsoft 365||v=spf1 include:spf.protection.outlook.com ~all|
|v=spf1 include:_spf.google.com ~all|
|Yahoo||v=spf1 include:_spf.mail.yahoo.com ~all|
|SendGrid||v=spf1 include:sendgrid.net ~all|
|Zoho||v=spf1 include:zoho.com ~all|
|GoDaddy||v=spf1 include:secureserver.net ~all|
|Amazon SES||v=spf1 include:amazonses.com ~all|
Before copying and pasting these SPF values, check the official documentation of the respective email service provider to make sure it is up to date.
How SPF works
Now that you understand all the parts of the SPF record, let's understand how it works in the real world with an example:
v=spf1 ip4:18.104.22.168/30 include:_spf.google.com include:spf.mandrillapp.com -all
This SPF record authorizes all the servers having IP addresses 22.214.171.124—126.96.36.199, Google servers, and Mailchimp servers to send emails on your domain's behalf. All other servers except these are explicitly stated as unauthorized (due to -all).
Let's say the Gmail server receives a forged email message that claims to be sent from your domain. The Gmail server will query the DNS for the SPF record and check whether the server (from where the email message was sent) is actually listed there. Since it was a forged message, the IP address will not be listed in the SPF value, and the SPF check will fail. Ultimately, the Gmail server will mark that message as spam or permanently reject it. Of course, there is much more going on under the hood, but this is how it works in a nutshell.
Important points about SPF records
- All the IP addresses, domain names, and third-party services that you use to send emails should be listed in the SPF record.
- There should be only one SPF record in a domain. Having multiple SPF records causes problems.
- The maximum DNS lookups are limited to 10 by the SPF specification. If lookups exceed this limit, the SPF check will fail. See the troubleshooting section for additional details.
- Keep your SPF record updated by removing outdated vendor names that are no longer in use, and keep only active sending domains and services.
Set up and validate the SPF record
The easiest way to generate an SPF record is to use the SPF record generator by MXToolBox. It offers an easy-to-use wizard. If you don't want to use any third-party service, make sure you understand the syntax of SPF as discussed above, and then create your SPF record accordingly.
To publish the SPF record in your domain, log on to the DNS management page and add a new TXT record, as shown in the screenshot below:
You might see slightly different options depending upon your DNS registrar, but the idea of adding the SPF record is the same everywhere. You must choose TXT under the record type when you create the SPF record.
Once you publish the TXT record in DNS, give it some time to propagate through the DNS servers, and then use the SPF record checker to validate your SPF record. This tool validates the record and reports whether there are any problems with the record. Moreover, it also shows the number of DNS lookups, as shown in the following screenshot. This is helpful in verifying that lookups do not exceed 10.
By the way, if you don't want to use any online tool, you could use the nslookup command, as shown below:
nslookup -q=txt yourdomain.com 188.8.131.52 This command uses Google DNS (184.108.40.206, which is optional) to query TXT records in yourdomain.com.
Troubleshoot SPF problems
When you publish your SPF record in DNS, remember that DNS propagation can take a while. So don't worry if your newly added SPF record couldn't be validated. Give it some time, and then try to validate again. If it still doesn't work, see the following points to troubleshoot:
- Syntax Errors—Make sure there is no syntax error, such as an extra space, typo, comma, etc., in your SPF record.
- Multiple SPF records—When you change your email service provider or hosting provider, they suggest adding their own SPF record. As a result, you might end up having multiple SPF records in your domain. Make sure there is only one SPF record and that it includes all the email sending servers and services.
- The DNS record type 99 (SPF) has been deprecated—When the SPF was in development, its requirements were stricter, and a dedicated DNS record of type 99 (SPF) was needed. However, support for the SPF record type ended in 2014. Now, you need to publish the SPF record as a type 16 (TXT) record. The above error indicates that you have selected the SPF record type while publishing it. To resolve this error, delete the old record and create a new record, choosing TXT as the record type.
- DNS lookup limit exceeded—The maximum DNS lookups are limited to 10 by the SPF specification. Mechanisms such as include, redirect, a, and mx trigger a DNS lookup in your SPF record. When you use such mechanisms multiple times, the lookup limit is exceeded, and the SPF check will probably fail. To get around this problem, avoid using multiple mechanisms that trigger a DNS lookup, and consider using ip4 or ip6 whenever possible.
- Missing qualifier at the end—Never forget to add the qualifier (- or ~) with the all mechanism at the end. For example, if your SPF record looks like this: v=spf1 a ip4:220.127.116.11 all, you're essentially authorizing everyone (*) to send emails on your domain's behalf, which makes your SPF record pretty much useless.
You see that SPF is important to prevent your email messages from landing in your recipients' spam folders. Unfortunately, SPF alone is not enough for guaranteed email delivery. The use of SPF together with DKIM and DMARC is highly recommended to set up proper email authentication and signing.
Subscribe to 4sysops newsletter!
In my next post I will describe how to configure DKIM and I will cover DKIM and DMARC in one of my next articles.