Unlocking the Secrets of the SPF Record: A Comprehensive Guide

SPF records are important for getting your email messages properly authenticated by this method (known as Sender Policy Framework). A proper setup of SPF records is an important part of establishing a good foundation for email deliverability.

Your SPF records basically indicate which sending email servers and IP addresses are allowed to send emails on behalf of your domain. When your email hits the receiving servers, they will perform lookups against your SPF record values to see if the sending server/IP is on your list of allowed senders.

If so, then the message passes SPF authentication. If not, then the message fails SPF authentication and could get quarantined (placed into spam) or outright rejected.

The purpose behind this SPF authentication process is so that illegitimate messages from sending servers/IPs that you did not approve should get filtered out.

SPF Record Requirements
You'll need a SPF record for every domain or subdomain that you are going to actively send emails from.

Additionally, SPF records do not replace the need for DKIM and DMARC records. They all work in conjunction with each other, and you'll need to have all three types of records.

Creating a SPF Record
To create a SPF record, you'll need to add a TXT type record into your DNS records host. To do this, you'll need to log into your web-hosting or CDN console and navigate to the DNS records section. There, you can add, edit, or delete DNS records.

Before you add your SPF record though, you'll need to understand the structure of its tags and values. Here's an example of a typical SPF record:

v=spf1 a mx include:_spf.google.com include:_spf.salesforce.com ~all

Let's break down the component parts.

• The "v=spf1" simply identifies the record as being a SPF-type record.

• The "a" and "mx" values means that when evaluating SPF authenticity, to accept it as passing if the A-records or the MX-records of the sending domain in the Return-Path match. While these are often included, if you are trying to minimize SPF lookups, you may be able to remove these, in cases where the referenced IPs in your A and MX records are not actually being used as outbound mailing IPs in the Return-Path.

• The two "include:" indicators are explicit authorizations of domains that we allow to send email on our behalf. In this case, that indicates Google (via Gmail) and Salesforce. Notice it's a variant of spf subdomains on each of those platforms. The exact syntax should be provided by your platform itself. So each time we want to authorize a new platform to send out our emails on our behalf, we'd need to consider adding another "include:" to the existing SPF record. The include values for SPF records can also be direct IP address or IP address ranges, such as include:ip4:192.168.0.1 or include:ip4:192.0.2.0/24

In many cases, the platforms you send from use their own domains in the Return-Path, so it actually bypasses the need to include: them in your SPF records, as the lookup occurs on their DNS; though this creates a problem of SPF alignment.

• The "~all" is actually differentiated from the "-all" (tilda vs dash). The ~ version indicates a Soft Fail vs. the dash version indicating a Hard Fail, which indicates to Fail the authentication and to reject the email. In a large part, these indicators were precursors of DMARC, where you defined a bit of how you'd like your emails to be treated in the case of failed SPF authentication.

Note that it's important to avoid using "+all" because it whitelists all email sources, and "?all" is neutral, which means it neither passes nor fails SPF checks.

Getting SPF Record Values
Each of your email sending platforms should have detailed deliverability documentation that'll help guide you on the exact "include:" values to add to your existing SPF records. This is the best place to search in order to find these values. Remember, every sending platform needs to have some route eventually to a valid SPF record or else SPF authentication will fail and cause deliverability problems.

Common SPF Mistakes
SPF PermErrors can occur when:

1. One domain has multiple SPF records
   
   
2. The SPF record contains syntax errors
   
   
3. DNS lookups exceed the allowed limit of 10
   
   

Multiple SPF Records
The first is pretty straightforward. You never want to have more than one SPF record on each domain or subdomain. So if you have say two SPF records like this on the root domain:

v=spf1 a mx include:_spf.google.com ~all

v=spf1 a mx include:mxsspf.sendpulse.com ~all

You'll instead want to combine them into one record:

v=spf1 a mx include:_spf.google.com include:mxsspf.sendpulse.com ~all

This comes into play because most of the instructions for adding SPF from your ESPs will say add a TXT record, but if you have an existing SPF record, what you really need to do is to add in the 'include' part to the existing record.

Also if you have no SPF records, then the receiving server won't have a reference point for evaluating against pass/fail under the SPF framework. Different inboxes may treat these cases differently, ranging from business as usual to outright rejecting or quarantining your email messages. It's always good practice to define a SPF record as a SPF record is necessary in order to achieve optimal deliverability.

SPF Syntax Errors
The second error case is fairly straightforward, if you have a syntax error in the record…like if you didn't tag it with the required 'v=spf1' or used invalid symbols.

Excessive SPF DNS Lookups
The third error case is a bit tricky. It indicates that you have too many elements in your record and generates more than 10 DNS lookups. Now, it is deceptively easy to hit this limit because a single element in the record can actually generate multiple lookups.

If you find that you are passing the threshold limit, you could delete unnecessary includes or look into SPF record flattening, which basically converts all the text lookups to raw IP addresses/ranges, which do not count against the limit.

You can check your SPF lookup number with a tool like MXToolBox.

SPF Alignment
SPF references the records of the domain that's in the Return-Path, not the Friendly From address. The authentication process then runs through the lookups on the SPF record for that domain until it either finds a match or gets to the end and fails SPF.

Often when sending from third-party ESPs, the ESP's domain is used by default in the Return-Path and not your own domain.

This comes into play with SPF alignment that's part of the DMARC SPF evaluation, namely it'll make SPF alignment fail, even as SPF itself can be registered as a pass.

So what can we do about this? The answer lies in a "Custom Return-Path" domain, which can indeed achieve SPF alignment even when you're using a third-party ESP (Email Service Provider).

The process works by setting a specific subdomain on your own domain to be used as the Return-Path for emails sent by the ESP. This is accomplished by creating a CNAME record that points to a domain provided by the ESP.

Summary
Configuring your SPF records correctly for your sending domains and subdomains helps set your email deliverability efforts on a solid foundation. We hope this has helped demystify some of the confusions around these SPF records!