Having an SPF record is crucial to email deliverability. Not having an SPF record, or having an improperly set up SPF record with the wrong SPF syntax, SPF elements, or SPF variables, can cause email deliverability nightmares. For example improperly set SPF, or no SPF at all, is a primary reason that email will end up in the spam folder at Gmail. Here, in plain English, is everything you need to know about what needs to be in your SPF record, and, equally important, what needs to not be in your SPF record.
[Note: If you aren’t sure what an SPF record does, or generally are shaky about email authentication, please read our plain English explanation of SPF and other email authentication mechanisms.]
What All the Elements and Variables in an SPF Record Mean
As an example, here is our SPF record for ‘isipp.com’:
v=spf1 ip4:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 ip6:2600:1f16:ff:cb00::11 include:_spf.google.com include:send.aweber.com ~all
And here is what each element means:
‘v=spf1’ means that this is SPF version 1.
‘ip4’ means “Here are the IPv4 IP addresses that are authorized to send email on our behalf.”
‘ip6’ means “Here are the IPv6 IP addresses authorized to send email on our behalf.”
‘include’ is used with domains, typically the domains of email service providers and other third-parties who are authorized to send email on your behalf. In our example, we use Aweber to send out email ‘from’ isipp.com, so the inclusion of “include:send.aweber.com” tells the inbox providers and ISPs “ISIPP uses Aweber to send some email, so if you get email “from” isipp.com that is sent through Aweber, it’s legitimate and you should accept and deliver it.”
And this brings us to “all”, which is the element that causes the most confusion and delivery issues.
What Exactly Does ‘All’ Mean and Do in SPF?
In an SPF record “all” can be thought of as “all of the email you receive that isn’t from one of the IP addresses or domains that are listed in our SPF record.”
In other words, it’s instructions to inbox providers and ISPs about what they should do with any (all) email that they receive “from” you, but that isn’t coming from one of the IP addresses or sending platforms you have specifically listed and authorized in your SPF record.
The actual instruction (“here’s how to handle email that doesn’t come from an authorized sending source”) is communicated to email receivers by the symbol that prefaces the word “all”. These prefixes are referred to as “tags”, “operators” or “elements” (they all mean the same thing, just different people call them different things), and here is what they mean, again using ISIPP as an example:
A dash in front of the word ‘all’ (“-all”) means that any email that claims to come from isipp.com but that is not coming from one of the explicitly listed sources should be rejected. Period.
A tilde in front of the word ‘all’ (“~all”) tells email receivers to do what is known as a “softfail”. A soft fail means they should not reject the email, but that when they accept it they should give it stricter scrutiny and perhaps mark it as spam, or as bulk.
The above two classifications (-all means ‘reject’ and ~all means ‘softfail’) mean two very different things which often confuse email senders. If your email is rejected it means that it never even made it past the border of the receiving system’s server. Access denied.
If your email is softfailed it means that your email was accepted to get past the border of the receiving system, but that is all that it means. It does not mean that your email will be delivered to the inbox, and it is as l ikely as not to go into the spam folder, or maybe even disappear and not seem to be delivered anywhere at all. How a softfail is treated is entirely up to the inbox provider, ISP, or other receiver, and will also depend on many other factors as determined by the spam filtering algorithms at the receiving system.
These two operators (- and ~) are the most commonly used, and the only two we recommend using. Most email senders use the tilde (~) because they don’t want to risk their email not getting delivered at all, however senders who are concerned about their name being used for phishing (financial institutions, for example) will use the dash (-).
An easy way to remember the difference between the two is that a dash is a straight line, and it means that the email should be rejected straightaway. A tilde is a wavy or fuzzy line, and it means that it’s unclear (“fuzzy”) whether the email is really from you, so needs to be accepted and checked out further.
The other two operators are + and ?:
A plus sign in front of the word ‘all’ (“+all”) means “literally anyone can send email claiming to be us and you should accept it.”
A question mark in front of the word ‘all’ (“?all”) will be taken to mean that you have no SPF policy at all; you can think about it as the response that someone who has no idea what SPF is gives you when you ask about their SPF policy (“?”).
Don’t use either a +all or a ?all in your SPF. Ever. Just don’t do it.
Finally, Two Big SPF Gotchas of Which You Need to Be Aware
When our customers are having delivery issues the first place we look is their SPF records, for what we hope by now are obvious reasons. But there are a couple of things which can cause your SPF to fail besides the above, and we see them more often than you might think:
Having more than one SPF record
SPF records are definitely not a case where more is better. You must have one, and only one SPF record. If you have more than one SPF record they will both fail, and the email you send will be treated as having no SPF record at all, or worse.
Improperly or incorrectly including a domain
This one trips up so many senders. When you are including a domain (such as _spf.google.com and send.aweber.com in our example) it is critical that you only include the domain that the platform has set up for you to include in your SPF record. For example, Google has set up _spf.google.com specifically for those who send email through Google to include in their own SPF records. The reason that this is critical is that when an inbox provider checks your SPF record, they will also check the SPF records associated with the domains listed in your SPF record. For example, if we send email through Google “from” isipp.com, then the inbox provider who receives that email will check our SPF record, and then also check the SPF records associated with _spf.google.com. Why is this important? Because if your SPF record triggers more than 10 lookups, it will fail. Google has set up _spf.google.com to anticipate and accommodate that, and that’s why Google tells you to put _spf.google.com in your SPF record. If instead you simply put “google.com” in your SPF record, the receiving system checking your SPF record will be treated to a deep dive of hundreds or even thousands of Google’s SPF records, and after the first 10 your SPF will fail.
We hope that this straightforward, plain English explanation of SPF elements has been useful! If you have any questions feel free to send them to us at firstname.lastname@example.org.