- What Is an SPF Record
- How SPF Records Work
- Common SPF Mechanisms
- SPF Qualifiers
- Why Having an SPF Record Is Important
- What SPF Record You Should Use
- How to Set Your SPF Record
- How to Check Your SPF Record
- Why SPF Alone Is Not Enough
- Beyond SPF: The Need for DKIM and DMARC Records
If you’re here you’ve probably been asked to configure your domain SPF record while setting up a business email address. If you’re not sure what that is, you’re in the right place!
In this post we’ll explain what the SPF record is, and how to set it up correctly.
What Is an SPF Record
SPF is one of the most important DNS records for emails.
An SPF record specifies which mail servers are allowed to send emails on behalf of a domain name. SPF stands for Sender Policy Framework.
SPF is, in essence, a way for domain owners to protect themselves against impersonators, by providing to recipient mail servers a way of verifying the legitimacy of the sender.
Here’s how it looks like, taken here from a hypothetical domain nicedomain.com:
nicedomain.com. 3600 IN TXT "v=spf1 mx ~all"
The SPF record is actually a TXT record, a flexible type of DNS record. What makes it an SPF record specifically is the part in double quotes. The properties of any TXT record are:
- The host, or name (
- The TTL (
- The value, or text, inside the double quotes (
"v=spf1 mx ~all").
The first two properties are common to all DNS records (see our post DNS Records Explained for more information on those). The
IN TXT part is just DNS syntax to indicate the record type.
Let’s breakdown the interesting part:
v=spf1 mx ~all.
v=spf1refers to the version of SPF being used.
mxrefers to the domain MX record, it’s one of 8 possible mechanisms.
~is called a qualifier, those are used alongside mechanisms.
allis another mechanism.
I’ll state what this particular record means, and we’ll move on to explain how to understand any SPF record.
This particular one means than only the server specified in the MX record should be allowed to send email from @nicedomain.com addresses, and that emails originating from other servers should be flagged as SOFTFAIL.
No worries, we’ll explain everything.
How SPF Records Work
Recipient mail servers compare the IP address an email comes from to the allowed IP addresses listed in the SPF record of the
Return-Pathemail address domain (a.k.a envelope sender domain). Emails originating from non allowed IP addresses are more likely to be tagged as spam or be rejected.
The SPF record starts with the version. It’s just
v=X where X is the version number, which turns out to always be 1 in practice. Pretty easy.
Now the important part. An SPF record contains a list of mechanisms separated by spaces. Each mechanism acts as a filter matching IP addresses of a certain category. Qualifiers are used to instruct how to treat the matching IP addresses of each mechanism.
The absence of a qualifier on a mechanism implicitly means that matching IP addresses are allowed to send emails on behalf of the domain name. Also equivalent to the
+ (PASS) qualifier.
Other qualifiers, like
~ (SOFTFAIL) and
- (FAIL) instruct the recipient server to soft reject (i.e. treat as potential spam), or reject the email.
Almost always, the list of mechanisms ends with the
all mechanism, usually the only one to have an explicit qualifier (either
-). For instance:
"v=spf1 mx ip4:652.325.36.21 include:shops.shopify.com ~all"
That’s because the
all mechanism matches all IP addresses. That setup therefore means that each mechanism apart from the
all one allows a particular set of IP addresses, while the
all one instructs to reject or soft reject other IP addresses.
Whenever a recipient mail server receives an email, it looks up the SPF record of the domain in the sender email address and checks the IP address of the sending mail server against the IP addresses listed in the SPF record. The email is treated differently depending on the result.
If the result is FAIL or SOFTFAIL, the email has a much higher probability of being delivered to the recipient’s junk or spam folder, while a PASS result increases its probability of being delivered to the inbox.
The email address taken as the sender address is what’s called the
Return-Path address, also referred to as the “Envelope Sender” address, or sometimes the “Mail From” or the “bounce” address.
That address is considered as the “true” sender of an email, and is the one to which a notification would be sent back in case of a delivery failure. It is used as part of the SMTP protocol, the language in which mail servers talk to each other.
Return-Path address is present in the email headers (what you see above the email body when you open the email “source”). In the Why SPF Alone Is Not Enough section we’ll see that SPF’s use of that address only is a flaw.
That’s really the crux of it. An SPF record is an IP filtering protection to assess the legitimacy of IP addresses sending emails on behalf of a domain name.
Okay, we’ve explained how an SPF record works. But we still haven’t really covered the various mechanisms availables. Here we go!
Common SPF Mechanisms
We won’t cover all of the 8 types of mechanisms, because only a few are usually needed, but you can find the full list here.
The “mx” Mechanism
Have you guessed it? Yes, the
mx mechanism matches the IP address(es) of the server(s) in the domain MX record.
This one should always be in your SPF record, without qualifier (or the
When you send an email from a domain email address, the mail server pointed to by your MX record is usually the one doing the actual sending. Thus, it must be allowed to do so.
If you don’t have any SPF record on your domain, any server is considered allowed. Therefore, having an SPF record not allowing the server from your MX record is worse than not having an SPF record at all.
The “a” Mechanism
Similarly to the
mx mechanism, the
a mechanism matches IP addresses in the A and AAAA records of the domain.
Not used that often, it can be useful if the server your domain name points to is doing some email sending on behalf of your domain name.
The “ip4” and “ip6” Mechanisms
ip6 mechanisms match specific IP addresses. Use it with a colon followed by the IP address. For instance:
"v=spf1 mx ip4:203.325.36.21 ip6:2001:0db8:85a3:0000:0000:8a2e:0370:7334 ~all"
The “include” Mechanism
include mechanism includes the SPF record of another server. It’s often used to allow third party services to send emails on behalf of your domain name.
The mechanism is followed by a colon and the domain name holding the SPF record to include.
"v=spf1 mx include:some.domain.name.com ~all"
These services usually provide a domain name to include in your SPF record via the
include mechanism. In the case of Shopify:
"v=spf1 mx include:shops.shopify.com ~all"
This one says to allow whatever server is allowed in the SPF record of shops.shopify.com.
We can see what that allows exactly by looking at the SPF record of shops.shopify.com (using the
dig command here):
peter@home:~$ dig TXT shops.shopify.com ... shops.shopify.com. 3600 IN TXT "v=spf1 ip4:22.214.171.124 ip4:126.96.36.199 ~all" ...
The IP addresses you see there belong to Shopify and correspond to their mail servers doing the sending of emails for online shops built with their software.
If you own a Shopify eCommerce, it is strongly recommended you include Shopify’s SPF into your own SPF record, to avoid having your eCommerce emails being flagged as spam.
The “all” Mechanism
We’ve seen that one earlier. As its name suggests, the
all mechanism matches all IP addresses. It simply always matches.
It is almost always used with a
~ (SOFTFAIL) or
- (FAIL) qualifier to treat all IP addresses not matching other mechanisms in the SPF record as not allowed to send on behalf of the domain name.
all mechanism basically takes the role of a bouncer. Not on the list? Won’t pass.
We’ve discussed qualifiers already, but for the sake of it, here’s the full list of them:
+(PASS): emails from matching IP addresses are allowed. Omitting a qualifier on a mechanism is equivalent to using the
?(NEUTRAL): neutral flag, rarely used.
~(SOFTFAIL): emails from matching IP addresses should be treated as possible spam (the recipient mail server may take various actions depending on its anti spam protection policies).
-(FAIL): emails from matching IP addresses should be rejected.
Why Having an SPF Record Is Important
The SPF record was invented to fight email spoofing, a technique is often used in phishing attempts.
With SPF, you only allow legitimate mail servers to send emails on behalf of your domain name. This makes it more difficult for impersonators to send fraudulent emails from email addresses using your domain name.
Therefore, SPF increases security, both for your recipients and your organization, while at the same time better protecting your brand.
A direct consequence of this is on deliverability. Mail services grade emails differently depending on whether the sender domain uses SPF, and in case it does, on the result of the SPF test.
An email passing the test will be far more likely to be trusted, and therefore delivered successfully to the recipient inbox. Conversely, an email failing the test will likely be treated as spam or junk. SPF therefore improves deliverability.
Finally, since using SPF reduces the amount of abuse committed with your domain name, you also better protect the reputation of your domain. Email services and other Internet services will better trust your domain name over time, further improving your deliverability. SPF improves your domain’s reputation.
You may have noticed I didn’t exactly say that with SPF your domain email addresses would be completely protected. That’s because using SPF alone is flawed, as we’ll discuss. A full protection also requires DKIM and DMARC records.
What SPF Record You Should Use
We said it already, your SPF record should always include the
mx mechanism. Without it you’d be forbidding your own mail service from handling your email sending, as it is supposed to be.
What else? Well, you SPF record should include any other mail server susceptible to send on behalf of your domain name.
Often, that includes some CMS or website builder like Shopify, and/or a bulk mailing service like Sendgrid. For such cases, you’ll likely have to use the
include mechanism. Have a look at those services documentations.
If you have set up some other mail server of yours doing email sending from one of your domain addresses, be sure to include it as well, either via the
ip6 mechanism or via the
include one if that server has a domain name (don’t forget in that case to create an SPF record with an
a mechanism on the DNS for that server domain).
Finally, always use an
all mechanism at the end. As qualifier it is usually recommended to use
~ (SOFTFAIL), just in case you’d have forgotten to include some IP addresses in your SPF record. If you’re certain you’ve included everything, the
- (FAIL) qualifier is safer.
Here’s an example. Let’s say we’ve built a Shopify eCommerce and Shopify sends emails using our domain name to customer on purchases. We’re using postale.io as base mail service for our regular emails, and we’re using Sendgrid for marketing campaigns. We also run a custom mail server we’ve set up on IP 239.532.174.65 for some notification emails.
We know that nothing else is supposed to send emails using one of our domain email addresses as sender. Our SPF record would look like this:
"v=spf1 mx include:shops.shopify.com include:sendgrid.net ip4:239.532.174.65 -all"
At postale.io, the default SPF record recommended to fit most people includes the MX record IP addresses (i.e. postale.io’s mail servers) and soft fails on other IP addresses, just in case.
"v=spf1 mx ~all"
How to Set Your SPF Record
As with any DNS record, you can set the SPF record of your domain by logging in to your domain provider website and opening the domain DNS editor there.
If you’re using postale.io as your domain email service, a recommended SPF record is given in the DNS configuration guide, and on the DNS diagnostic tool, available from your domain page on the admin interface.
How to Check Your SPF Record
There are many free services out there to check what your SPF record looks like. Apart from the
dig command mentioned earlier, mxtoolbox.com for instance has a pretty neat tool.
If your domain email service is postale.io, there’s also the all-in-one DNS diagnostic page available from your domain page on the admin interface.
Why SPF Alone Is Not Enough
The SPF record is a great way to protect your domain name from impersonators. But it alone is not nearly enough. There are a few reasons for this.
First, the SPF record only checks the domain of the
Return-Path email address (a.k.a envelope address), as we mentioned in the How SPF Records Work section above.
The big issue with this is that this address is not the one you see in your mail app when you look up the sender email address of an email. That one is instead the
Return-Path and the
From addresses are located in the email headers (what you see above the email body when you open the email “source”). And as it turns out, the SMTP protocol allows putting two different addresses in each header. They don’t have to match.
Thus, someone with malicious intent could send an email from an envelope address of their own that has a domain with a valid SPF, while using your address in the
From header field. The SPF test in that case would pass. To protect yourself against this type of spoofing, you need a DMARC record.
In addition, the SPF record doesn’t check that the email hasn’t been modified along the way. An abuser could intercept and resend your email with modifications of its own. To protect yourself against that, you’ll need a DKIM record.
Last but not least, SPF records don’t actually enforce a policy by themselves. They are only recommendations for recipient mail servers. It is ultimately the responsibility of the mail server to accept or reject the email, or to flag it as spam.
Only if you also have a DMARC record will you be able to enforce a particular policy.
Beyond SPF: The Need for DKIM and DMARC Records
If you’re interested in protecting your domain emails from spoofing and improving your deliverability, don’t just stop at the SPF record! Complete your setup with DKIM and DMARC.
A DKIM record will protect your domain emails from tampering by providing recipient mail servers with a digital fingerprint to verify their integrity.
A DMARC record will additionally prevent spoofing of the
From header field, while allowing you to enforce a particular policy in case SPF and DKIM tests fail.
To get acquainted with these records and see how to use them, check out our dedicated guides below.
Do you need to set up a DKIM record on your domain DNS, but you’re not sure what it is and how to do it? Search no longer! In this post we’ll explain everything you need to know about DKIM records. What Is a DKIM Record DKIM stands for DomainKeys Identified Mail. It’s a way…
In this post we’ll explore in detail what a DMARC record is, why you should absolutely have one, and how to use it. If you want to understand DMARC, come along! What Is a DMARC Record DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Quite a mouthful. It designates a system allowing domain owners…