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.
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 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
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
- 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.
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:
Multiple SPF Records
- One domain has multiple SPF records
- The SPF record contains syntax errors
- DNS lookups exceed the allowed limit of 10
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