The SPF Record Explained

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:

1. The host, or name (nicedomain.com.).
2. The TTL (3600).
3. 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=spf1 refers to the version of SPF being used.
• mx refers to the domain MX record, it’s one of 8 possible mechanisms.
• ~ is called a qualifier, those are used alongside mechanisms.
• all is 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

TL;DR

Recipient mail servers compare the IP address an email comes from to the allowed IP addresses listed in the SPF record of the Return-Path email 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 ~ or -). 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.

The 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 + one).

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.

Note

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

The ip4 and 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

The 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"

For instance you can use that mechanism to allow email marketing services, such as Sendgrid, Mailchimp, and the likes.

Or perhaps you have created your website with a service like Shopify or Wix, and you need to allow these to send emails using your domain name (contact form, transactional emails, …).

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:35.203.94.235 ip4:35.203.3.51 ~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.

The all mechanism basically takes the role of a bouncer. Not on the list? Won’t pass.

SPF Qualifiers

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 + qualifier.
• ? (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.

Note

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 ip4/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.

To help you with that, you may find this list of DNS guides for common providers useful. Here’s an example with domain on Namecheap:

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.

Other handy services include spf-record.com and mail-tester.com, to name a few.

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 From address.

Both 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.

Related Posts