Flatten SPF Record Safely

12 October 2026 · DMARC Engine · 13 min read

How to Safely Flatten SPF Record to Avoid Exceeding DNS Lookup Limits

The SPF PermError Conundrum: When DNS Lookups Go Overboard

The PermError, or permanent error, is a critical issue that can arise when an SPF record exceeds the DNS lookup limit, causing mail delivery failures. This limit, set at 10 lookups, is often overlooked, leading to unexpected problems. A typical example of an SPF record that may exceed this limit is one that includes multiple nested include mechanisms, such as

v=spf1 include:_spf.example.com include:_spf2.example.com include:_spf3.example.com ?all

In this case, each include directive can trigger additional DNS lookups, quickly reaching the 10-lookup threshold. When this happens, the receiving mail server will return a PermError, effectively blocking all emails from the domain.
To avoid this issue, it is crucial to carefully plan and optimise SPF records, taking into account the potential number of DNS lookups required. One approach is to use a single, centralised SPF record that includes all necessary IP addresses and domains, rather than relying on nested include mechanisms. For instance,

v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 include:example.net -all

This record includes two IP addresses and a single domain, keeping the number of lookups relatively low. However, as the number of IP addresses and included domains grows, so does the risk of exceeding the lookup limit. In a hosted or managed setup, such as the one provided by DMARC Engine, this issue can be mitigated through automated SPF record analysis and optimisation tools, which help identify and flatten overly complex records.
In our experience, a common mistake is to overlook the cumulative effect of multiple include mechanisms, which can lead to a sudden surge in DNS lookups and subsequent PermErrors. To centre our efforts on preventing such issues, we recommend regularly reviewing and simplifying SPF records, using tools and services that can help identify potential problems before they arise. By taking a proactive approach to SPF record management, organisations can minimise the risk of delivery failures and ensure their emails reach their intended recipients.
It is also worth considering the colour of the SPF record, as a -all or +all default policy can significantly impact the handling of emails that do not match the specified IP addresses or domains. In general, we recommend using a -all policy to reject emails that fail SPF checks, as this provides an additional layer of security against spam and phishing attacks. However, this approach requires careful consideration of the potential impact on legitimate emails, and should be implemented in conjunction with other security measures, such as DKIM and DMARC.

Understanding the 10-Lookup Limit: A Deep Dive

The 10-lookup limit is a critical consideration when configuring SPF records, as exceeding this limit can result in a permerror, causing email delivery issues. This limit is imposed by the RFC, and it is essential to understand how it applies to SPF records. For instance, consider an SPF record that includes multiple include mechanisms, such as

v=spf1 include:_spf.google.com include:_netblocks.amazon.com include:mail.zendesk.com -all

Each include mechanism can trigger additional DNS lookups, which can quickly add up. In a hosted setup, such as ours at DMARC Engine, we often see customers with complex SPF records that include multiple third-party services, such as mailing lists or marketing platforms. To avoid exceeding the 10-lookup limit, it is crucial to carefully plan and optimise SPF records. One approach is to use the ip4 and ip6 mechanisms to specify IP addresses directly, rather than relying on include mechanisms. For example,

v=spf1 ip4:192.0.2.1 ip6:2001:db8::1 include:_spf.google.com -all

This approach can help reduce the number of DNS lookups required to validate an SPF record. However, it requires careful management of IP addresses and can become cumbersome to maintain. In our experience, a balanced approach that combines direct IP addresses with carefully selected include mechanisms is often the most effective way to optimise SPF records while avoiding the 10-lookup limit. By understanding how the 10-lookup limit applies to SPF records and taking a thoughtful approach to record configuration, organisations can help ensure reliable email delivery and maintain a strong security posture.

Flattening SPF Records: A Step-by-Step Guide

To safely flatten SPF records and avoid exceeding DNS lookup limits, it is essential to follow a structured approach. The first step is to identify the current SPF record and its components. For instance, consider the following SPF record snippet:

v=spf1 include:_spf.google.com include:mail.zendesk.com include:_netblocks.mimecast.com -all

In this example, the record includes multiple third-party services, each of which may have its own set of IP addresses or sub-includes. To flatten this record, we need to resolve these includes and merge the resulting IP addresses into a single record.

The next step is to resolve each include and retrieve its IP addresses. This can be done using DNS lookup tools or by manually querying the DNS server. For example, the _spf.google.com include may resolve to a set of IP addresses, such as:

v=spf1 ip4:216.58.194.174 ip4:216.58.194.174 ip4:216.58.194.174 -all

However, it is crucial to note that some includes, such as those from cloud providers, may have a large number of IP addresses or use techniques like CIDR blocks to reduce the number of entries. In such cases, it may be necessary to use tools or scripts to help resolve and merge these addresses.

Once all the includes have been resolved and their IP addresses retrieved, the next step is to merge these addresses into a single record. It is essential to ensure that the resulting record does not exceed the 255-character limit and stays within the 10-lookup limit. A flattened version of the original record might look like this:

v=spf1 ip4:216.58.194.174 ip4:103.122.166.0/24 ip4:104.196.12.0/24 -all

In a hosted or managed setup, such as the one provided by DMARC Engine, the process of flattening SPF records can be automated, and the resulting records can be optimised to ensure they stay within the lookup limits. Also, these services often provide tools and guidance to help customers navigate the complexities of SPF record management.

It is also important to consider the trade-offs involved in flattening SPF records. While a flattened record may reduce the risk of exceeding DNS lookup limits, it can also make it more difficult to manage and update the record, particularly if the included services change their IP addresses frequently. Therefore, it is crucial to weigh the benefits of flattening against the potential drawbacks and consider alternative approaches, such as using a more efficient include mechanism or implementing a record management strategy that balances security and deliverability. By taking a structured and informed approach to flattening SPF records, organisations can help ensure the security and integrity of their email communications while minimising the risk of delivery issues.

Real-World Examples: Before and After Record Flattening

When dealing with complex SPF records, it is crucial to understand how flattening can impact deliverability. Consider a company like Example Ltd, which has multiple mail servers and uses various third-party services for marketing and support emails. Their initial SPF record might look like this:

v=spf1 include:_spf.example.net include:_spf.marketing.example.com include:_spf.support.example.io -all

Each of these included domains has its own set of IP addresses and possibly further includes, leading to a deep nesting that can easily exceed the 10-lookup limit. For instance, the _spf.example.net record might include another record:

v=spf1 ip4:192.0.2.1 ip4:198.51.100.1 include:_spf.subdomain.example.net -all

And the _spf.subdomain.example.net record could include yet another, creating a chain that quickly adds up. In a hosted or managed setup like ours at DMARC Engine, we often see customers who are unaware of these nested includes and the potential for lookup limit errors.

To safely flatten such a record, we need to expand all includes and list IP addresses explicitly. This might result in a record that looks like this:

v=spf1 ip4:192.0.2.1 ip4:198.51.100.1 ip4:203.0.113.1 ip6:2001:db8::1 -all

Notice how the flattened record directly lists all the IP addresses, avoiding the need for nested includes and thereby reducing the risk of exceeding the lookup limit. However, this approach requires regular updates to ensure that all IP addresses are correctly listed and that none are missed, which can be a challenge, especially in dynamic environments.

In our experience, managing SPF records for numerous customers, the key to successful flattening is thorough monitoring and regular review of aggregate reports. These reports can highlight issues such as permerrors due to exceeded lookup limits, allowing for prompt adjustments to the SPF record. For example, if after flattening, a report shows that emails from a specific IP are being rejected due to a missing entry in the SPF record, it's a clear indication that the record needs to be updated to include that IP address. Our managed setup at DMARC Engine automates the monitoring of these reports, providing customers with actionable insights to optimise their SPF records and improve deliverability. By combining careful record flattening with ongoing monitoring and adjustments, companies can significantly reduce the risk of SPF-related delivery issues.

Trade-Offs and Considerations: Balancing Security and Deliverability

When flattening SPF records to avoid exceeding DNS lookup limits, it is crucial to balance security and deliverability considerations. A flattened SPF record may improve deliverability by reducing the number of DNS lookups, but it can also increase the risk of spoofing if not implemented correctly. For instance, if a record includes multiple third-party services with varying levels of security, flattening the record may compromise the overall security posture.
Consider a scenario where a company uses a hosted email service, such as Google Workspace, and also uses a marketing automation tool like Mailchimp. The original SPF record might look like this:

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

Flattening this record would require including the IP addresses of both Google and Mailchimp, which can be cumbersome to manage and may lead to errors. In a hosted or managed setup, such as DMARC Engine, this process can be optimised by using automated tools to fetch and update the IP addresses of third-party services, thereby reducing the administrative burden.
However, this approach also introduces the risk of IP address changes going unnoticed, which can lead to email delivery issues. To mitigate this risk, it is essential to implement a robust monitoring system that tracks changes to SPF records and alerts administrators to potential issues. By carefully weighing these trade-offs and implementing a well-considered flattening strategy, organisations can optimise their SPF records to improve deliverability while maintaining a strong security posture. In practice, this means prioritising the security of high-risk services, such as email hosting, while accepting a slightly higher risk for lower-risk services, like marketing automation tools.
Ultimately, the key to successful SPF record flattening is to strike a balance between security and deliverability, taking into account the specific needs and risks of each organisation. This may involve accepting a degree of compromise, such as using a more permissive SPF record for certain services, in order to optimise overall email deliverability. By adopting a nuanced and informed approach to SPF record management, organisations can navigate the complexities of email security and ensure reliable delivery of their emails.

Monitoring and Optimising: Using Aggregate Reports to Inform SPF Decisions

To safely flatten SPF records and avoid exceeding DNS lookup limits, it is crucial to monitor and optimise your setup using aggregate reports. At DMARC Engine, we centre our approach around the analysis of these reports to inform SPF decisions. A typical aggregate report might contain information on the number of messages that failed SPF checks, the IP addresses involved, and the domains that were attempting to send emails on behalf of our customers.
For instance, a report might show a high number of SPF failures from a particular IP address, such as 192.0.2.1, which could indicate that this IP is not included in the current SPF record.

<record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>100</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>none</dkim>
 <spf>fail</spf>
 </policy_evaluated>
 </row>
</record>

In a hosted setup like ours, we can automate the process of parsing these reports and updating the SPF records accordingly. However, in a self-managed setup, this process would need to be handled manually, which can be time-consuming and prone to errors.
To optimise SPF records, we recommend regularly reviewing aggregate reports to identify potential issues, such as unexpected IP addresses or domains. This information can then be used to update the SPF record, for example, by adding the IP address 192.0.2.1 to the record, as shown below:

v=spf1 ip4:192.0.2.1 include:_spf.example.com -all

It is also essential to consider the colour of the SPF record, as a record with too many includes or IP addresses can still exceed the 10-lookup limit. In such cases, we might need to flatten the record further or use techniques like CIDR aggregation to reduce the number of lookups.
By closely monitoring aggregate reports and making data-driven decisions, we can ensure that our SPF records are optimised for both security and deliverability, and that we are not inadvertently blocking legitimate emails or exceeding DNS lookup limits. This approach allows us to strike a balance between the two, which is critical in today's email landscape, where security and deliverability are equally important.
In our experience, a well-optimised SPF record can significantly reduce the number of SPF-related issues, and we have seen a notable improvement in deliverability for our customers who have implemented this approach.
Ultimately, the key to safely flattening SPF records is to carefully monitor and analyse aggregate reports, and to make informed decisions based on the data. By doing so, we can ensure that our SPF records are effective, efficient, and optimised for both security and deliverability.

Common Pitfalls and Edge Cases: Lessons from the Trenches

When flattening SPF records, a common mistake is to overlook the impact of nested includes, which can still lead to exceeding the 10-lookup limit. For instance, consider a record like

"v=spf1 include:_spf.example.com include:_spf.anotherdomain.com -all"

where both _spf.example.com and _spf.anotherdomain.com contain additional includes. In a hosted setup like ours at DMARC Engine, we centre our approach on optimising these records to avoid such pitfalls, often by manually flattening these nested includes into a single record.
A related edge case is the use of ptr records, which can introduce additional lookups. We recommend avoiding ptr records altogether in favour of more explicit ip4 and ip6 entries, as these are more straightforward to manage and less likely to cause issues.
In real-world scenarios, the colour of the problem changes when you have to balance security with deliverability, and this is where experience and a deep understanding of the trade-offs come into play. For example, overly restrictive SPF records can lead to legitimate emails being flagged as spam, while overly permissive records can leave you open to spoofing. Our approach at DMARC Engine is to carefully analyse aggregate reports to inform our SPF decisions, ensuring the best possible balance between these competing demands.

How to Safely Flatten SPF Record to Avoid Exceeding DNS Lookup Limits