Understanding the Limitations of SPF in Email Authentication
by
Reading Time: 7 min
Sender Policy Framework or SPF doesn’t suffice when it comes to securing corporate emails from phishing and spamming attacks. SPF is an email authentication protocol that protects the email receiver from spoofed emails by checking if the sending IP address is authorized in the domain’s DNS record. However, 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. DMARC builds upon SPF (and DKIM) to provide enhanced security and reporting. This blog discusses these SPF problems and how DMARC helps overcome these SPF limitations.
Key Takeaways
- SPF has a 10-lookup limit, which can lead to validation failures (Permerror) and delivery issues if exceeded.
- SPF checks the Return-Path domain, not the visible From address, allowing attackers to spoof the sender identity.
- SPF authentication can fail when emails are forwarded, as the forwarding server’s IP is often not listed in the original sender’s record.
- DMARC overcomes SPF limitations by enforcing alignment between the From address and the authenticated domain, and provides reporting for visibility into email channels.
- Optimizing SPF records by removing unused mechanisms or using SPF flattening can help stay within the lookup limit.
What are the SPF Record Limitations?
There are 3 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. When you exceed this limit, the SPF implementation is considered invalid and your email fails SPF, potentially harming your email delivery rates.
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 (also known as the envelope sender or MFrom) and not the From address (header sender or From address) that recipients see in their email clients. Recipients generally don’t pay much attention to the hidden Return-Path address and only focus on the visible From address when they open an email. Hackers take advantage of this loophole to attempt phishing attacks by using a fake domain in their Return Path address (which passes SPF) and forging the From address with a legitimate or legitimate-looking one. Since most people aren’t aware of the Return Path address and don’t check it, this trick allows attackers to easily circumvent SPF protection.
3. Email Forwarding Issues
SPF has another critical failure point that can harm email deliverability. When you’ve implemented SPF on your domain and someone forwards your email, the forwarded email can get rejected due to your SPF policy. That’s because the forwarding process changes the server sending the message (and its IP address), but the original sender’s From address often remains the same. The receiving server sees the original From address but checks the IP address of the *forwarding* server against the original sender’s SPF record. Since the forwarding server’s IP address typically isn’t included in the original sender’s SPF record, the check fails, potentially causing the forwarded email to be rejected or marked as spam.
Simplify Security with PowerDMARC!
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.
-
Consider SPF Record Flattening
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. Flattening involves replacing mechanisms like ‘include’ with the actual IP addresses they resolve to, directly reducing the number of DNS lookups needed during validation. However, flattening requires careful management; if the IP addresses behind an included service change, the flattened record becomes outdated and must be manually updated to prevent legitimate emails from failing SPF checks. Automatic SPF flattening tools can help manage this process.
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 domain and the domain authenticated by SPF (the Return-Path domain).
So, if an email passes the SPF checks (meaning the sending IP is authorized for the Return-Path domain) but the Return-Path domain isn’t the same as the From address domain, DMARC alignment for SPF fails. For an email to pass DMARC overall, it needs to pass either SPF *with* alignment or DKIM *with* alignment. This prevents the common phishing tactic where the From address is spoofed while the Return-Path passes SPF. DMARC also introduces reporting capabilities, providing domain owners with feedback on emails claiming to be from their domain, including authentication results (SPF, DKIM, DMARC, alignment) and information about sending sources. This visibility helps identify misconfigurations, forwarding issues, and malicious spoofing attempts.
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. SPF records often use mechanisms like “include”, “a”, “mx”, and “ptr” which require DNS lookups. If the SPF record contains many such mechanisms, especially nested includes (where an included domain’s SPF record also contains includes), it can quickly exceed the 10 DNS lookup limit, leading to SPF verification failures (Permerror) and potential email delivery issues.
To overcome this limitation, SPF record flattening is used. SPF record flattening is a technique that replaces lookup-causing mechanisms (primarily ‘include’, but potentially ‘a’ and ‘mx’ as well) 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 the IP addresses are listed directly instead of needing further lookups.
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 structure would have resulted in more than 10 DNS lookups. This technique helps prevent SPF Permerrors and reduces the risk of SPF record validation failures due to DNS query timeouts or temporary DNS server issues. However, as mentioned earlier, flattened records require maintenance to stay accurate when underlying IP addresses change.
Challenges of Implementing SPF in Large Enterprises
SPF has forced the limitation of no more than 10 lookups to prevent DoS and DDoS attacks against DNS infrastructure during SPF validation. Unfortunately, these lookups can add up very fast, especially in large enterprises. Earlier companies often operated their own mail servers, however, now they heavily rely on numerous third-party senders for marketing, transactional emails, CRM, support systems, etc. Each third-party service often requires an ‘include’ mechanism in the SPF record, which counts as one lookup, and their own SPF records might contain further lookups. This creates a problem as adding multiple services can quickly cause the domain to reach or exceed the 10-lookup limit, leading to the Permerror issues described above. Managing these numerous sources and staying within the limit while ensuring all legitimate mail is authorized becomes a significant challenge.
Domain & Email Security Expert at PowerDMARC
Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.
Latest posts by Ahona Rudra (see all)
