The Sender Policy Framework (SPF) is a technique that prevents email spoofing. In this article, you will learn the importance of the SPF record and how to correctly configure it in your domain's DNS so that emails sent from your domain are not marked as spam by the recipient.
Latest posts by Surender Kumar (see all)

If your email messages are landing your recipients' spam folders, the likeliest cause is a missing or misconfigured SPF record in the sending domain.

Gmail could not verify that it actually came from name@gmail.com avoid clicking links downloading attachments or replying with personal information

Gmail could not verify that it actually came from name@gmail.com avoid clicking links downloading attachments or replying with personal information

Modern email providers might even completely reject your message with an error, as shown in the following screenshot:

Our system has detected that this message is 550 5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail 550 5.7.1 this message has been blocked

Our system has detected that this message is 550 5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail 550 5.7.1 this message has been blocked

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:

Understanding various parts of an SPF record

Understanding various parts of an SPF record

  1. The value of every SPF record starts with v=spf1, which indicates that it is an SPF (version 1) record.
  2. 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 ProviderSPF Value
Microsoft 365v=spf1 include:spf.protection.outlook.com ~all
Googlev=spf1 include:_spf.google.com ~all
Yahoov=spf1 include:_spf.mail.yahoo.com ~all
SendGridv=spf1 include:sendgrid.net ~all
Zohov=spf1 include:zoho.com ~all
GoDaddyv=spf1 include:secureserver.net ~all
Amazon SESv=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:192.167.0.0/30 include:_spf.google.com include:spf.mandrillapp.com -all

This SPF record authorizes all the servers having IP addresses 192.167.0.1—192.167.0.2, 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:

Publishing an SPF record in Cloudflare DNS

Publishing an SPF record in Cloudflare DNS

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.

Validating the SPF record for errors using the SPF record checker

Validating the SPF record for errors using the SPF record checker

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 8.8.8.8
This command uses Google DNS (8.8.8.8, which is optional) to query TXT records in yourdomain.com. 
Querying TXT records using nslookup in Windows

Querying TXT records using nslookup in Windows

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:

  1. Syntax Errors—Make sure there is no syntax error, such as an extra space, typo, comma, etc., in your SPF record.
  2. 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.
  3. 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.
  4. 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.
  5. 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:1.2.3.4 all, you're essentially authorizing everyone (*) to send emails on your domain's behalf, which makes your SPF record pretty much useless.

Conclusion ^

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.

avatar
Articles in series

Email authentication methods

  1. How to create an SPF Record: Prevent email spoofing
  2. How to configure DKIM
  3. DKIM vs. SPF
  4. Configure DMARC for SPF and DKIM
5 Comments
  1. bgavin 4 months ago

    Excellent.
    A truly excellent article.

  2. Nicholas Kulkarni 3 months ago

    Thank you for an excellent article. Showing how to return a txt record for a domain in NSLookup was very useful. The definition of “all” and its modifiers was particularly useful, everyone says end your SPF record with -all but nobody, until now, has explained why. Just one question please because it bugs me, what is the difference between -all and ~all.
    The examples you give all use the minus – sign but the records in the example table from other ISPs all use the tilde ~

    • Author
      Surender Kumar 3 months ago

      Hi,
      Tilde (~) qualifier denotes that the emails received from a server that is not specified in SPF record, are to be marked with soft-fail in envelope. Such messages are likely to be accepted by recipient servers.
      The minus (-) qualifier on the other hand enforces a strict policy to mark the messages with hard-fail and such messages are usually rejected by receiving mail servers.

      I hope this makes sense now.

      avatar
      • Nicholas Kulkarni 3 months ago

        Excellent, thanks for that it has been bugging me that I didn’t understand why I was seeing some records with ~ and others with –

        Off to edit my DNS to make sure it is Hard Fail not soft.
        Thanks 🙂

        avatar

Leave a reply

Your email address will not be published.

*

© 4sysops 2006 - 2022

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account