The DOs And DON’Ts Of Using SPF Records

Fix Your SPF Errors Now

Sender Policy Framework is one of the widely used email authenticating techniques. It is like declaring, “Yes, I am the owner of this domain. I allow my customer.io to send emails in my name.” As the recipient’s mailbox provider sees this signature in the sender’s emails, it authenticates the incoming messages because these are not phishing emails.

As more domains start implementing SPF records, it derives more value from the framework for anti-spam filters and mailbox providers. Creating and managing SPF records can indeed be cumbersome, and if you have a poorly configured SPF record with an incorrect SPF record syntax, it can give rise to deliverability issues; therefore, it is crucial to understand how to create an SPF record in detail.

Table of Contents

DOs and DON’Ts When Creating SPF Records

Here are some problems caused by an incorrect SPF record and how one can overcome them

Overly Permissive SPF Records – Being over-generous can backfire

One of the best features of Sender Policy Framework records is the ability to include a range of IP addresses in the CIDR notation instead of specifying them individually. One typo error can dramatically change the situation. Here is an SPF record example.

Correct Format with 0 at the end IP Range
142.0.176.0/20 4,096

As you can see, this range includes 4,096 IP addresses that the business can use for email delivery. Like the exclusion of the ‘0’ at the end, a typo error dramatically changes the picture.

Incorrect – Typo error without the 0 at the end IP Range
142.0.176.0/2 1,073,741,824

Missing one ‘0’ at the end allows nearly 25% of the internet traffic to use your email network. It gives a long rope to scammers to send spam messages using your email network.
An SPF record can be overly permissive if you end your SPF record with “+all.” It is a more dangerous situation as you permit the entire internet to send emails on your behalf.

Duplicate SPF TXT records – Be careful when creating SPF records

A domain may have only a single SPF record. Thus, you can have only one DNS TXT beginning with “v=spf1”. Having multiple records results in a permanent error.
The question arises as to how are multiple SPF records common. Organizations can deploy various services, whereby each provider could instruct them to create an SPF record. Organizations having numerous SPF records can merge them into a single statement. This example would be able to clarify it better:

“v=spf1 include:email-office365.com ~ all”
“v=spf1 include:_spf.google.com ~ all”

Here is how to create an SPF record single statement.

“v=spf1 include:email-office365.com include:_spf.google.com ~ all”

SPF Character Limits – Better to know your limits

RFC stipulates that SPF records have a 255-character limit for a single string. Records not complying with this stipulation can cause temporary or permanent errors.

Though you can have a maximum of 255 characters in a string, you can have more than one string in a DNS record. When a receiving email server analyzes such an SPF record with multiple strings, it concatenates them together without adding spaces.

While multiple strings are allowed, there is still a limit to the number of characters in your record. It is to ensure that you do not cause DNS packets to exceed 512 bytes. An ideal limiting figure should be around 460. You can create sub-records to split your single record across multiple records.

The number of DNS lookups allowed in SPF – Know what is allowed and what is not.

RFC specifications do not allow you to cause more than ten DNS lookups in your record. It is to prevent DoS attacks. Having more than ten lookups could return a permanent error. Here are some examples that can cause a DNS query.

Include
A
MX
PTR
Exists
Redirect

The following mechanisms do not count against the DNS query.

All
ip4
ip6

Duplicate IP Addresses and Subnets

As all SPF entries resolve to an IP address or a subnet, it could be easy to generate a duplicate entry when building up an exhaustive list of all systems that send emails. It can happen when your SPF record has an include statement. It could be the same IP or IPs within subsets you already have.

If your IP address remains the same throughout, you can use the ip4 or ip6 notations to avoid DNS lookups.

Other points to note

Here are some don’ts. It can result in rejection for the sender policy framework.

One should never use the “exists” mechanism to cause a significant security risk if misused.
Similarly, one should ensure that all mechanisms that use a domain-based implementation resolve correctly. Generally, system administrators do not remove legacy systems, like an on-premise exchange server replaced by Office365 cloud services. So, when the Sender Policy Framework Office 365 was updated to add Office365, you might not have edited to remove the on-premise system.
One should not use the SPF DNS record type as it has been deprecated in favor of TXT records.
Similarly, one should also not use the “ptr” mechanism because RFC has deprecated it in the recent draft of SPF.

We have seen that the Sender Policy Framework is essential for an organization because it protects their customers, brand, and network from spoofing and phishing attacks. Malicious actors can take advantage of your mistakes to send phishing emails, thereby denting your brand reputation. Therefore, knowing the DOs and DON’Ts of SPF records is critical, as an incorrect record does not serve its purpose.

MORE – Rejecting for sender policy framework