Sender Policy Framework or SPF doesn’t suffice when it comes to securing corporate emails from phishing and spamming attacks. SPF limit on the maximum number of DNS lookups and unalignment of the From address and domain cause implementation errors resulting in email deliverability issues. This blog discusses these problems and how DMARC helps overcome these SPF limitations. 

What are the SPF Record Limitations?

There are 2 major SPF limits that make it a bit tricky to implement and maintain. 

1. The SPF 10-Lookup Limit

When a user queries the DNS server, its validator resources like bandwidth, time, CPU, and memory are employed. To avoid any load on the validator, there’s an SPF limit of 10 additional lookups. However, the DNS query for the SPF policy record itself doesn’t count towards this limit.

As per RFC7208 section 4.6.4, the recipient’s mail server shouldn’t process further once the 10-lookup limit is reached. In such a case, the email rejects SPF validation with a Permerror error. SPF Permerror is one of the messages that commonly appear in the SPF implementation process. It causes email non-delivery and occurs if multiple SPF records exist on one domain, a syntax error pops up, or due to exceeded SPF record limits.

You can use the free SPF record checker tool to eliminate this error and ensure secured email conversations.

Moreover, according to RFC, a DNS query of a hostname found in an MX record shouldn’t generate more than 10 A records or AAAA records. If a DNS PTR query generates produces more than 10 results, only the first 10 results are displayed and used.  

2. The Human-Readable From Address

The second SPF limitation is that SPF records apply to specific Return-Path domains and not the From address. Recipients generally don’t pay much attention to the Return-Path address and only focus on the From address when they open an email. Hackers take advantage of this loophole to attempt phishing attacks by forging the From address.

The Impact of SPF Record Size on Email Delivery

When a recipient exceeds the SPF record limit, it fails SPF checks and a Permerror occurs. You can observe this error when using DMARC monitoring. The recipient can choose how to deal with emails having Permerror failure. They can choose it to reject its entry which means the email would bounce back. Some recipients configure it to show a ‘neutral’ SPF result (as if no SPF is used). They can also choose ‘fail’ or ‘softfail’ which means emails failing the SPF  authentication checks aren’t rejected but land in the spam folder. 

These results are also determined by considering the results of DMARC, DKIM, and spam rating. Exceeding the SPF limit impacts email deliverability by reducing the probability of emails to land in the primary inbox of the intended recipients. 

Validator assesses SPF policy from left to right and when a match on the sender IP address is found, the process stops. Now, depending on the sender, a validator may not always reach the lookup limit even if the SPF policy demands more than 10 lookups to fully evaluate. It creates difficulties in identifying SPF record limit-related email deliverability issues. 

How to Reduce the Number of Required Lookups?

It’s difficult for some domain owners to stay within the SPF limit of 10 lookups as the email exchanging habits have changed significantly from 2006 (the time when RFC4408 was implemented). Now, companies use multiple cloud-based programs and services with a single domain. So, the following are some ways to overcome this common SPF limitation.

  • Remove Unused Services

Assess your SF record and look if there are any unused or unrequired services. Check it for the ‘include’ or other mechanisms that show domains of services no longer in use.

  • Remove the Default SPF Values

The default SPF policy is usually set to ‘v=spf1 a mx’.  Since most A and AAAA records are used for web servers that may not send emails, hence, the ‘a’ and ‘mx’ mechanism aren’t required. 

  • Avoid Using the ptr Mechanism

The ptr mechanism is highly discouraged due to weak security and unreliability. The mechanism causes the SPF limit problem by requiring more lookups. Hence, it should be avoided as much as possible

  • Avoid Using the mx Mechanism

The mx mechanism is used for receiving emails, and not necessarily for sending them. That’s why you can avoid using it to stay within the SPF record limit set on lookups. If you are a cloud-based email service user, use the ‘include’ mechanism instead.

  • Use IPv6 or IPv4 

The IPv4 and IPv6 don’t need any additional lookups which means they help you not exceed the SPF limit of no more than 10 lookups. However, you need to stay updated and maintain the two mechanisms regularly as they are more prone to errors when not reconditioned.

  • Don’t Flatten SPF Records

Some resources claim that the more flattened (or shorter) the SPF policy, the better the domain reputation. They suggest this method for staying within the SPF record limits set on lookups. However, flattening is discouraged as it makes your record more prone to errors and required regular updations. 

The Role of DMARC in Overcoming SPF Limitations

DMARC addresses the SPF limitation of the human-readable From Address by requiring a match or alignment between the human-readable From field and the server authenticated by SPF.

So, if an email passes the SPF checks but the domain isn’t the same as the From address, DMARC overrules that authentication. This means the email fails the authentication test.

How does SPF record flattening help overcome the 10 DNS lookup limit

SPF record flattening is a technique used to optimize SPF (Sender Policy Framework) records to overcome the 10 DNS lookup limit for SPF. The 10 DNS lookup limit is a restriction imposed by many DNS resolvers, which limits the number of DNS queries that can be performed when verifying an SPF record for a domain.

When an email is received, the recipient’s mail server queries the sender’s domain’s DNS for its SPF record to verify if the sender is authorized to send emails from that domain. However, if the SPF record contains many nested includes, it can quickly exceed the 10 DNS lookup limit, leading to SPF verification failures and false-positive spam detections.

To overcome this limitation, SPF record flattening is used. SPF record flattening is a technique that replaces all nested include statements in an SPF record with their corresponding IP addresses or CIDR ranges. This reduces the number of DNS queries required to verify the SPF record, as each included domain is no longer queried individually.

By flattening the SPF record, the number of DNS queries required to verify the SPF record is significantly reduced, allowing email messages to pass SPF verification even if the original record had more than 10 DNS lookups. This technique also reduces the risk of SPF record validation failures due to DNS query timeouts or temporary DNS server issues.

Challenges of Implementing SPF in Large Enterprises

SPF has forced the limitation of no more than 10 lookups to prevent DoS and DDoS attacks. Unfortunately, these lookups can add up very fast, especially in large enterprises. Earlier companies operated their own mail servers, however, now they use third-party senders. This creates a problem as each can take up to 3 or 4 servers and you reach the limit very quickly.

In this article, we will explore how to optimize SPF record easily for your domain. For enterprises as well as small businesses who are in possession of an email domain for sending and receiving messages among their clients, partners and employees, it is highly probable that an SPF record exists by default, which has been set up by your inbox service provider. No matter if you have a pre-existent SPF record or you need to create a new one, you need to optimize your SPF record correctly for your domain in order to ensure that it causes no email delivery issues.

Some email recipients strictly require SPF, which indicates that if you do not have an SPF record published for your domain your emails may be marked as spam in your receiver’s inbox. Moreover, SPF helps in detecting unauthorized sources sending emails on behalf of your domain.

Let us first understand what is SPF and why do you need it?

Sender Policy Framework (SPF)

SPF is essentially a standard email authentication protocol that specifies the IP addresses that are authorized to send emails from your domain. It operates by comparing sender addresses against the list of authorized sending hosts and IP addresses for a specific domain that is published in the DNS for that domain.

SPF, along with DMARC (Domain-based Message Authentication, Reporting and Conformance) is designed to detect forged sender addresses during email delivery and prevent spoofing attacks, phishing, and email scams.

It is important to know that although the default SPF integrated into your domain by your hosting provider ensures that emails sent from your domain are authenticated against SPF if you have multiple third-party vendors to send emails from your domain, this pre-existent SPF record needs to be tailored and modified to suit your requirements. How can you do that? Let’s explore two of the most common ways:

  • Creating a brand new SPF record
  • Optimizing an existing SPF record

Instructions on How to Optimize SPF Record

Create a Brand New SPF Record

Creating an SPF record is simply publishing a TXT record in your domain’s DNS to configure SPF for your domain. This is a mandatory step that comes before you start on how to optimize SPF record. If you are just starting out with authentication and unsure about the syntax, you can use our free online SPF record generator to create an SPF record for your domain.

An SPF record entry with a correct syntax will look something like this:

v=spf1  ip4:38.146.237 -all

v=spf1Specifies the version of SPF being used
ip4/ip6This mechanism specifies the valid IP addresses that are authorized to send emails from your domain.
includeThis mechanism tells the receiving servers to include the values for the SPF record of the specified domain.
-allThis mechanism specifies that emails that are not SPF compliant would be rejected. This is the recommended tag you can use while publishing your SPF record. However it can be replaced with ~ for SPF Soft Fail (non-compliant emails would be marked as soft fail but would still be accepted) Or + which specifies that any and every server would be allowed to send emails on behalf of your domain, which is strongly discouraged.

If you already have SPF configured for your domain, you can also use our free SPF record checker to lookup and validate your SPF record and detect issues.

Common Challenges and Errors while Configuring SPF

1) 10 DNS Lookup limit 

The most common challenge faced by domain owners while configuring and adopting SPF authentication protocol for their domain, is that SPF comes with a limit on the number of DNS lookups, which cannot exceed 10. For domains relying on multiple third-party vendors, the 10 DNS lookup limit exceeds easily which in turn breaks SPF and returns an SPF PermError. The receiving server in such cases automatically invalidates your SPF record and blocks it.

Mechanisms that initiate DNS lookups: MX, A, INCLUDE, REDIRECT modifier

2) SPF Void Lookup 

Void lookups refer to DNS lookups which either return NOERROR response or NXDOMAIN response (void answer). While implementing SPF it is recommended to ensure DNS lookups do not return a void answer in the first place.

3) SPF Recursive loop

This error indicates that the SPF record for your specified domain contains recursive issues with one or more of the INCLUDE mechanisms. This takes place when one of the domains specified in the INCLUDE tag contains a domain whose SPF record contains the INCLUDE tag of the original domain. This leads to a never-ending loop causing email servers to continuously perform DNS lookups for the SPF records. This ultimately leads to exceeding the 10 DNS lookup limit, resulting in emails failing SPF.

4) Syntax Errors 

An SPF record may exist in your domain’s DNS, but it is of no use if it contains syntax errors. If your SPF TXT record contains unnecessary white spaces while typing the domain name or mechanism name, the string preceding the extra space would be completely ignored by the receiving server while performing a lookup, thereby invalidating the SPF record.

5) Multiple SPF records for the same domain

A single domain can have only one SPF TXT entry in the DNS. If your domain contains more than one SPF record, the receiving server invalidates all of them, causing emails to fail SPF.

6) Length of the SPF record 

The maximum length of a SPF record in the DNS is limited to 255 characters. However, this limit can be exceeded and a TXT record for SPF can contain multiple strings concatenated together, but not beyond a limit of 512 characters, to fit the DNS query response (according to RFC 4408). Though this was later revised, recipients relying on older DNS versions would not be able to validate emails sent from domains containing a lengthy SPF record.

Optimizing your SPF Record

In order to promptly modify your SPF record you can use the following SPF best practices:

  • Try typing down your email sources in decreasing order of importance from left to right in your SPF record
  • Remove obsolete email sources from your DNS
  • Use IP4/IP6 mechanisms instead of A and MX
  • Keep your number of INCLUDE mechanisms as low as possible and avoid nested includes
  • Do not publish more than one SPF record for the same domain in your DNS
  • Make sure your SPF record doesn’t contain any redundant white spaces or syntax errors

Note: SPF flattening is not recommended since it isn’t a one-time deal. If your email service provider changes their infrastructure, you’re going to have to change your SPF records accordingly, every single time.

Optimizing Your SPF Record Made Easy with PowerSPF

You can go ahead and try implementing all those above-mentioned modifications to optimize your SPF record manually, or you can forget the hassle and rely on our dynamic PowerSPF to do all that for you automatically! PowerSPF helps you optimize your SPF record with a single click, wherein you can:

  • Add or remove sending sources with ease
  • Update records easily without having to manually make changes to your DNS
  • Get an optimized auto SPF record with the single click of a button
  • Stay under the 10 DNS lookup limit at all time
  • Successfully mitigate PermError
  • Forget about SPF record syntax errors and configuration issues
  • We take away the burden of resolving SPF limitations on your behalf

Sign up with PowerDMARC today to bid adieu to SPF limitations forever!