How to Deploy SPF Email Authentication
The first email authentication method SPF – Sender Policy Framework – was introduced in early 2000.
SPF means that only authorized senders can send from a domain, and prevents all unauthorized senders from doing so. SPF allows the receiving email server to verify that an email message claiming to come from a domain truly comes from an IP address authorized by that domain’s administrator.
1. How SPF Works
To understand how it works, consider the following example.
Imagine that your business domain is myhomebusiness.com. You send emails to your client and subscribers from firstname.lastname@example.org.
The email server that you use to send emails has an IP address of 184.108.40.206.
Malicious senders use a scam email server with the IP address 220.127.116.11 to send spoofed emails.
When your email server connects to the recipient’s mail server, the receiving server does two things:
1) it extracts the domain name from the “Envelope From” address; in our example, it’s myhomebusiness.com.
2) it checks the myhomebusiness.com’s SPF record published in DNS to see if the connecting IP address is listed there. If the IP address is listed in the SPF record, the SPF check passes, otherwise, it fails.
Let’s say your SPF record is
v=spf1 ip4:18.104.22.168 -all
It means that only the email messages sent from the IP address 22.214.171.124 can pass SPF check, while any emails sent from any other IP address will fail. Therefore, no message from the scam server at the IP address 126.96.36.199 will ever pass SPF check.
Consider SPF as a whitelist of legitimate IP addresses which can send emails on behalf of your domain.
The SPF authentication result is then used to check the DMARC authentication.
It’s easy to see whether SPF check passes or fails in Gmail. Login to your Gmail web account, open the message in question and use the “Show Original” option to examine the information about the message.
2. How to Create an SPF Record
SPF provides mechanisms, qualifiers, and modifiers to allow domain administrators to specify allowed IP addresses in a highly flexible way.
Let’s examine the SPF record:
v=spf1 ip4:188.8.131.52 -all
v=spf1 defines the version of SPF. It’s always “spf1”. Everything that follows is a combination of mechanisms, qualifiers, and/or modifiers which tell if a host is authorized to send emails.
The ip4 mechanism specifies an IPv4 address range allowed to send emails for the domain in question. In our example, one IP address 184.108.40.206 is allowed.
The -all part at the end consists of the – qualifier and the all mechanism which specify that if none of the previous mechanisms matches, the SPF check fails.
Here is another example:
v=spf1 a mx include:_spf.example.com -all
This record allows the following IP addresses to send emails on behalf of your domain myhomebusiness.com:
– if myhomebusiness.com has an address record (A or AAAA) that can be resolved, the resolved value is allowed (the a mechanism);
– if myhomebusiness.com has an MX record that can be resolved, the resolved value is allowed (the mx mechanism);
– any IP address passing SPF authentication using another domain’s SPF record at _spf.example.com, is allowed (the include:_spf.example.com mechanism).
An SPF record that prevents any email from being sent on behalf of a domain looks like this:
When you use an email delivery service, they usually ask you to add their domain to your existing SPF record using the include mechanism.
For example, Google will ask you to include _spf.google.com (example, v=spf1 include:_spf.google.com ~all), SendGrid will ask you to add include:sendgrid.net to your SPF record so that email messages sent through the particular email service pass SPF authentication.
Each time an email message reaches an email service host, the host queries the DNS to perform SPF check.
The SPF specification enforces that the number of mechanisms and modifiers that do DNS lookups does not exceed 10 per SPF check, including lookups caused by the use of the “include” mechanism or the “redirect” modifier. If this number is higher than 10 during a check, a PermError is returned.
The include, a, mx, ptr, and exists mechanisms and the redirect modifier do count against this limit.
The all, ip4, and ip6 mechanisms do not require DNS lookups and therefore do not count against the 10-DNS-lookup limit. The exp modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated.
Let’s examine the google.com’s SPF record:
v=spf1 include:_spf.google.com ~all
the include mechanism in this record count 1 against the limit.
Next is _spf.google.com’s SPF record:
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all
the 3 include mechanisms in this record count 3 against the 10-DNS-lookup limit.
All of the records below _netblocks.google.com _netblocks2.google.com _netblocks3.google.com resolve to a flat list of IP addresses. So none of them counts against the limit.
Therefore, the total number of mechanisms and modifiers that do DNS lookups in our example SPF record is 4 (1+3).
If your SPF record exceeds the 10-DNS-lookup limit, SPF authentication returns a permanent error showing “too many DNS lookups”. This error is interpreted in DMARC as fail. Therefore, when it happens, it has a negative impact on your email deliverability.
You can use an SPF checker tool to count the DNS lookups in the SPF record on your domain to make sure it stays below 10. If the number of DNS lookups is higher than 10, you need to “flatten” your SPF record so that all your emails can land in the Inbox as desired.
GlockApps has the built-in tool called SPF Flattener which automates SPF record flattening.
Enter the domain and click “Check SPF”.
The tool will show the number of DNS querying mechanisms used in the SPF record on your domain.
Read more about how to optimize your SPF record and fix DNS lookup errors.
3. How to Publish an SPF Record
After you created the SPF record, you need to publish it to the DNS of your domain in order the receiving email server can pick it up.
Here are the steps:
1. Log in to your account with your hosting service.
2. Click on the domain in question.
3. Click the DNS button.
4. If you’ve never added an SPF record on the domain before, click “Add”.
5. Select TXT from the Type drop-down menu. Enter @ for the Host field. Enter the SPF record as the TXT Value.
6. Click “Save”.
In case you already have an existing SPF record, search for a TXT record with a value starting with v=spf1 and edit it.
Note that if you check the newly published SPF record, it can take up to 1 hour before it appears in any SPF checker tool, due to DNS propagation.
4. How to Check an SPF Record
We’ve already mentioned the GlockApps SPF Flattener where you can enter your domain and get the SPF record verified.
The SPF Flattener:
– checks if the SPF record syntax is correct;
– makes sure the number of mechanisms and modifiers in the SPF record that do DNS lookups is under 10;
– “flattens” the SPF record into a list of plain IP addresses, so that you can check them one by one, in case you need to track down some obstinate SPF issues.
To test how different mailbox providers resolve your SPF record, you can use the GlockApps spam tests. The spam report will show whether or not your SPF record passed the check with a particular provider.
5. Important Things about SPF
It is important to note that SPF does not validate against the “From” email domain. SPF looks at the “Enveloper From” or “Return-Path” domain to validate the originating server. It’s the email address that receiving mail servers use to notify the sending mail server of delivery failures.
So an email can pass SPF check regardless of whether or not the “From” email address is fake. The “From” email address is what the recipients see in their email clients. Even if the SPF check fails, the message can still be delivered. That final decision about delivery is taken by the receiving mailbox provider. When it happens, the recipient can become a victim of a phishy email with a spoofed sending address.
Another problem is that SPF fails when an email message is forwarded. When the message is relayed by an intermediate server, and the intermediate server’s IP address is not listed in the domain’s SPF record, the SPF check fails. It’s not a common case, however.
Although SPF may not be perfect, it is better to use it rather than not use. Email messages may still be delivered without setting up SPF but doing it increases the change to reach the Inbox. A published SPF record is an additional trust signal to mailbox providers.
Used in isolation, SPF won’t solve all of your deliverability issues, but in combination with DKIM and DMARC, it will prevent email spoofing and domain abuse and increase your delivery rates.