What is SPF (Sender Policy Framework) and How to Set it Up

Setting up your SPF (Sender Policy Framework) will not only improve your email deliverability but will also help you maintain a positive domain reputation and reduce the likelihood of your email message going to the spam folder.

SPF is one layer of email authentication published within your Domain Name System (DNS) records as a DNS TXT record.

After implementing SPF, SPF records allow the receiving mail server to verify if an email sender is authorized to send mail on behalf of the domain owner. Only authorized IP addresses and domain names will allow SPF authentication to pass when they send email.

Almost all mail servers support SPF to improve email security as a whole. SPF protects your sending domain from phishing attacks and will help prevent messages from unauthorized email senders from reaching your recipient’s inbox.

Continue reading to learn more about SPF including:

In order to understand how SPF works, consider the following example.

Imagine that your business domain is myhomebusiness.com. You send emails to your clients and subscribers from newsletter@myhomebusiness.com.

The email server that you use to send messages from has an IP address of 196.212.66.44.

When you send email, your email server connects to your recipient’s mail servers, then, the receiving mail servers do two things:

1) They extract your domain name from your email headers or “Envelope From” address (for our example, it’s myhomebusiness.com)

2) Then, the receiving servers check myhomebusiness.com’s DNS record for your SPF information to see if your sending IP address is listed there. If your IP address is listed in the SPF information, the SPF check passes, otherwise, the message fails SPF.

So if some spammer attempts to use a scam email server with the IP address 123.123.2.1 to send spoofed emails, they will fail SPF and are more likely to land in the spam folder.

Let’s say your SPF record is

v=spf1 ip4:196.212.66.44 -all

That means that only the email messages sent from the IP address 196.212.66.44 can pass authentication, while any emails sent from any other servers will fail. Therefore, no message from the scam server at the IP address 123.123.2.1 will ever pass SPF.

Think of SPF as a whitelist of authorized IP addresses and email servers that can send legitimate email on behalf of your domain.

The SPF authentication result is then used to check your DMARC authentication.

How do I know if my SPF Passes?

It’s easy to see whether the SPF passes or fails in Gmail. After you send email, log in to your Gmail web account, open your message and use the “Show Original” option to examine the information about the message.

Sender Policy Framework (SPF) provides mechanisms, qualifiers, and modifiers to allow domain administrators to specify allowed IP addresses in a highly flexible way.

What do SPF Records Mean?

Let’s examine the SPF record:

v=spf1 ip4:196.212.66.44 -all

v=spf1 defines the version of SPF. It will always be “spf1”. Everything that follows is a combination of mechanisms, qualifiers, and/or modifiers that a domain’s administrators have set to tell the receiving server if a sender permitted to send mail.

The ip4 mechanism specifies an IPv4 address range allowed to send emails for the specific domain in question. In our example, one IP address is permitted: 196.212.66.44.

The -all part at the end consists of the “–” qualifier and the “all” mechanism which specifies that if none of the previous mechanisms matches, any SPF checks will fail SPF.

Learn more about SPF Failure including Soft Fail, Hard Fail, and how that affects DMARC: SPF Soft Fail – Everything about SPF Failures

Here is another example:

v=spf1 a mx include:_spf.example.com -all

This record allows the following IP addresses to send email on behalf of your domain: myhomebusiness.com:

– The a Mechanism: if myhomebusiness.com has an address record (A or AAAA) that can be resolved, the resolved value is allowed;

– The mx Mechanism: if myhomebusiness.com has MX records that can be resolved, the resolved value is allowed;

– The include:_spf.example.com Mechanism: any IP address passing SPF authentication using another domain’s SPF record at _spf.example.com, is allowed.

An SPF record that prevents any mail from being sent on behalf of a domain looks like this:

v=spf1 -all

When you use an email delivery service, they usually ask you to add their domain to your existing SPF records using the “include” mechanism.

For example, if you send an email message using Google, they 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 mail sent through the particular email service pass SPF email authentication.

10-DNS-Lookup Limit

Each time an email message reaches a recipient server, the receiving server queries your DNS to perform an SPF check.

It’s important that your SPF Policy (number of mechanisms and modifiers) does not exceed 10 per SPF check. This includes lookups caused by the use of the “include” mechanism or the “redirect” modifier. If this number is higher than 10 during a check, it results in a PermError.

The include, a, mx, ptr, exists mechanisms, and the redirect modifier also 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 google.com’s SPF record:

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

The include mechanism in this record count as 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 as 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 email authentication returns a permanent error showing “too many DNS lookups”. This error is interpreted in DMARC as a fail. Therefore, when this happens, it has a negative impact on your email deliverability in the “eyes” of spam filters.

Learn More about DMARC Fails: DMARC Fail: What Causes DMARC Failure in 2023?

How can I count DNS lookups?

You can use an SPF checker tool to count the DNS lookups in the SPF record for 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 your recipient’s inbox.

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 for your domain.

Read more about how to optimize your SPF record and fix DNS lookup errors.

After you have created your SPF record, you need to publish it in your domain’s DNS settings as TXT records so that the receiving email servers can pick it up.

Follow these 6 steps to publish your SPF TXT records:

1. Login to your account with your hosting service.

2. Click on your domain.

3. Click the DNS button.

4. If you’ve never added an SPF TXT 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 TXT record, search for a TXT record with a value starting with v=spf1 and edit it.

Once you have your SPF record added, it can take up to 1 hour before it appears in any SPF checker tool, due to DNS propagation.

As we mentioned, the GlockApps SPF Flattener helps you can enter your domain and get your SPF record verified.

The SPF Flattener:

– checks if the SPF record syntax is correct;

– makes sure the number of mechanisms and modifiers in your SPF record is under the 10 DNS lookups limit;

– “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.

An important thing to note is 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. Receiving email servers use the email address 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. The receiving mail server makes the final decision whether to deliver the mail or not. If the mail does get delivered to the recipient’s inbox, the recipient can become a victim of phishing attacks from a spoofed sending address.

Another problem is that SPF fails when your relay email. Relayed email is a message that’s been forwarded by an intermediate server. If the intermediate server’s IP address is not listed in the domain’s SPF record, the email message’s SPF check will fail. However, it’s not common.

Although email messages may still be delivered without setting up SPF, it is better to implement it to increase your chances of reaching the inbox. A published SPF record is an additional trust signal to the recipient server.

Sender Framework Policy Takeaways:

Be sure to incorporate SPF records as an important building block to improving your email deliverability and email authentication by ensuring that your messages originate from your own domain when you send mail.

Also, be sure to exclude any domain not sending mail and define all sending domains including your primary domain and third-party services in your SPF TXT record within your DNS settings. This will help ensure that all your marketing and transactional email get delivered.

By itself, SPF won’t solve all of your deliverability issues. To achieve complete email authentication, set up SPF along with DKIM, DMARC, and BIMI to prevent email spoofing, domain abuse, and increase your delivery rates.

Read also:

DMARC Monitoring and Reporting: Step-by-Step Guide