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.