SPF is a record that belongs to the domain’s DNS. It is a simple TXT file (previously used SPF has been deprecated). In this file, domain owners specify the list of IP addresses (mail servers) that are authorized to send emails from a given domain. When an email arrives at a server that processes incoming mail on behalf of a recipient, a quick check is performed.
A server runs a DNS lookup of an “envelope sender address” (aka “return-path address”). When it finds an SPF record, it scans the list of authorized addresses for the record. If there’s a match, the result of an SPF test is positive. In any other case, the check is negative; in this case, a “SoftFail” will be triggered. This means that the server should still accept the email, but will mark the SPF check as failed, which serves as a reason for an email to be discarded.
Because of its wide adoption, SPF is considered to be a must-have for all regular email senders. Having SPF immediately increases the changes of valid email delivery. If you’re not sure if you have SPF set up or if it’s up to date, you can quickly check via easily available tools (for example, those from MX Toolbox).
Example of an SPF record
Now, let’s stop theorizing and see what an actual record looks like. If you were to look up our domain, you would find the following record:
v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.reply.io ~allLet’s examine this step by step:
- v=spf1 -> The beginning refers to the version of SPF in use. In almost every case, it’s simply “spf1’” – version 1, also known as SPF Classic.
- include: -> Here, we specified which domains we use to send emails from the mailtrap.io domain. As you can see, we use SendGrid, Reply.io, as well as Google (Google Apps to be specific). Optionally, an additional parameter can be added before “include”, but does not change anything here.
- ~all -> Finally, this specifies that all other domains are not authorized to send on our behalf. ‘~’ in this case means a SoftFail recommendation.
Instead of server names, you can also use IP addresses in both ip4 and ip6 formats. Here’s the example for SendGrid:
v=spf1 ip4:167.89.32.5 ip4:167.89.32.50 ip4:50.31.36.199 ip4:50.31.36.205 ip4:50.31.36.208 ip4:50.31.36.213 ip4:50.31.36.197 ip4:167.89.25.84 include:_spf.google.com include:partners.sendgrid.com include:_labs.sendgrid.com -allThere are several optional parameters that may be useful if you want your records to be more (or less) strict. For more about this, please check our article on SPF Records where we also address common misconceptions, SPF setup, and validation instructions.
How to use SPF correctly
SPF comes with several qualifiers that give an email server information about how to treat IPs/hosts outlined in an SPF record. The available qualifiers are:
- ~ -> SoftFail – accept emails but marks SPF as failed
- – -> Reject – reject emails
- + -> Pass – allow emails (if no qualifier is used, + is assumed)
- ? -> Neutral – no policy (results of a check are not marked)
Note that these are just suggestions given to a server; they can be ignored. An IP with a “Pass” policy may be rejected or sent to spam, while a ‘Reject’ policy may not stop an email from finding its way to an inbox.
In the example above, you can see two different approaches:
- SendGrid chose “-all” policy, which means they suggest rejecting all emails if they don’t meet the earlier criteria. This approach is generally recommended only for the most secure domains, as it can lead to legitimate emails getting discarded.
- Our SPF includes “~all” policy. IPs failing a test still have a chance to be accepted, but will be marked as “SPF failed”. This more relaxed approach is recommended for most email senders, and makes for a good balance between security and deliverability. The “Neutral” approach is also frequently used.
Note that when you use DMARC along with SPF, your SPF policy will not apply. To learn about DMARC and DKIM click here.