How to Flatten SPF Record for Complex Email Infrastructures: A Step-by-Step Guide

12 October 2026 · DMARC Engine · 11 min read

The Problem of Multiple SPF Records

When dealing with complex email infrastructures, one of the common issues that arise is the management of multiple SPF records. This can occur when an organisation has multiple domains, subdomains, or uses third-party services that require SPF validation. For instance, a company may have a primary domain, a subdomain for marketing campaigns, and another for customer support, each with its own set of authorised senders.
In a hosted setup like ours at DMARC Engine, we often see customers with multiple SPF records, which can lead to DNS lookup limits being exceeded, resulting in failed SPF validation. A typical example of this is when a customer has an SPF record for their primary domain, such as

example.com. IN TXT "v=spf1 include:_spf.example.com include:mailchimp.com ~all"

and another for their marketing subdomain,

marketing.example.com. IN TXT "v=spf1 include:_spf.marketing.example.com include:sendgrid.com ~all"

In such cases, the SPF record for the primary domain may include the subdomain's SPF record, causing the DNS lookup limit to be exceeded. To mitigate this, we recommend flattening the SPF records to reduce the number of lookups required.
A flattened SPF record would, for example, list all the IP addresses and include statements in a single record, rather than nesting them. This approach requires careful planning and management to ensure that all authorised senders are included and that the record does not exceed the 255-character limit per TXT record.
In our experience, a well-organised and flattened SPF record can significantly improve email deliverability and reduce the risk of SPF-related issues. By centreing the management of SPF records around a single, flattened record, organisations can optimise their email infrastructure and improve the overall colour of their email deliverability.

Understanding DNS Lookup Limits

When dealing with complex email infrastructures, it is crucial to understand the DNS lookup limits imposed by the SPF protocol. The SPF specification states that a maximum of 10 DNS lookups are allowed, after which the SPF record is considered invalid. This limit is in place to prevent excessive DNS queries, which can lead to performance issues and slow down email delivery.
For instance, consider a scenario where a company uses multiple email service providers, each with its own SPF record. The company's main SPF record might include multiple include mechanisms, such as:

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

In a hosted or managed setup, such as the one we use at DMARC Engine, we often see customers with complex email setups, where the number of DNS lookups can quickly add up. To avoid exceeding the lookup limit, it is essential to carefully plan and optimise the SPF record.
A common approach is to use a single, flattened SPF record that includes all the required IP addresses and mechanisms, rather than relying on multiple include statements. This not only helps to reduce the number of DNS lookups but also improves the overall performance and deliverability of emails.
By understanding the DNS lookup limits and taking steps to optimise the SPF record, companies can ensure that their emails are delivered reliably and efficiently, without being flagged as spam or blocked by recipient mail servers.

Flatten SPF Record: A Step-by-Step Guide

To flatten an SPF record, you need to identify all the IP addresses and hostnames that send email on your organisation's behalf, and then combine them into a single record. This process can be complex, especially for organisations with multiple email services, marketing tools, and internal systems. Start by gathering a list of all the IP addresses and hostnames, including any third-party services that send email for you. For example, if you use a marketing automation tool like Mailchimp, you will need to include their IP addresses in your SPF record.

When gathering IP addresses, consider both IPv4 and IPv6 addresses, as some email services may use one or both. You should also account for any subdomains that send email, as these may require separate SPF records. In a hosted or managed setup, such as the one we use at DMARC Engine, we provide tools to help customers manage their SPF records, including automated IP address detection and record generation.

Once you have your list of IP addresses and hostnames, you can start building your flattened SPF record. The record should start with the v=spf1 version identifier, followed by the IP addresses and hostnames, separated by spaces. For example:

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

In this example, the SPF record includes two IP addresses (192.0.2.1 and 198.51.100.1) and the Mailchimp SPF record (_spf.mailchimp.com). The -all directive at the end specifies that any email not sent from these IP addresses or hostnames should be rejected.

To avoid DNS lookup limits, you should try to keep your SPF record as short as possible. This means using IP addresses instead of hostnames where possible, and using include directives to reference other SPF records instead of listing all the IP addresses individually. For example, instead of listing all the IP addresses for a particular email service, you can include their SPF record, like this:

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

In this example, the SPF record includes the IP address 192.0.2.1 and the SPF record for example.com. This approach helps to keep the record short and avoids DNS lookup limits.

When flattening your SPF record, you should also consider the use of macros, such as %{i} and %{l}, which can help to simplify the record and make it easier to manage. For example:

v=spf1 ip4:%{i} include:%{l}._spf.example.com -all

In this example, the SPF record uses the %{i} macro to include the IP address of the current host, and the %{l} macro to include the domain name of the current host. This approach helps to simplify the record and make it easier to manage, especially in complex email infrastructures.

In a hosted or managed setup, we can help customers to automate the process of flattening their SPF records, and provide tools to help them manage their records and avoid DNS lookup limits. By following these steps and using the right tools, you can create a flattened SPF record that helps to prevent spam and protects your organisation's email infrastructure.

Real-World Examples of Flattened SPF Records

When dealing with complex email infrastructures, flattening SPF records is crucial to avoid DNS lookup limits and ensure proper email deliverability. Let's consider a few real-world examples to illustrate this point.

For instance, a company like Example Ltd, which uses multiple email service providers, such as Mailchimp, Sendgrid, and Amazon SES, may have a complex SPF record setup. Initially, their SPF record might look like this:

v=spf1 include:_spf.mailchimp.com include:sendgrid.net include:amazonses.com -all

However, this setup can lead to DNS lookup limits, as the number of lookups exceeds the recommended 10-limit. To flatten this record, we can use a technique called "SPF record rewriting" or "SPF flattening". This involves rewriting the SPF record to include only the IP addresses of the mail servers, rather than the include statements.

Using tools like SPF Flattener or by manually looking up the IP addresses, we can rewrite the SPF record as follows:

v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:199.232.69.0/24 ip4:167.89.106.0/23 include:example.com -all

In this example, we have replaced the include statements with the actual IP addresses of the mail servers. This approach helps to reduce the number of DNS lookups and ensures that the SPF record is within the recommended limit.

Another example is a company that uses a hosted email service like Google Workspace. In this case, the SPF record might look like this:

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

To flatten this record, we can use Google's recommended SPF record, which includes the IP addresses of their mail servers:

v=spf1 ip4:216.58.194.174 ip4:216.58.194.174 ip4:216.58.194.174 include:example.com -all

However, it's essential to note that using a hosted or managed setup, such as DMARC Engine, can simplify the process of managing SPF records. These services often provide automated tools for flattening SPF records and can help to optimise email deliverability.

In addition to these examples, it's also important to consider the use of IPv6 addresses in SPF records. As IPv6 becomes more widely adopted, it's crucial to include IPv6 addresses in the SPF record to ensure proper email deliverability. For instance:

v=spf1 ip6:2001:0db8:85a3:0000:0000:8a2e:0370:7334 -all

By including IPv6 addresses in the SPF record, companies can ensure that their emails are delivered correctly, even in environments that support IPv6.

In short, flattening SPF records is a crucial step in ensuring proper email deliverability, especially for companies with complex email infrastructures. By using techniques like SPF record rewriting and including IP addresses in the SPF record, companies can reduce the number of DNS lookups and ensure that their emails are delivered correctly.

Trade-Offs and Considerations for Flattening SPF Records

When flattening SPF records, a key consideration is the potential impact on email deliverability. For instance, if you have a complex email infrastructure with multiple senders, flattening your SPF record may lead to a higher risk of IP address overlaps, which can cause issues with DMARC alignment. To mitigate this, it is essential to carefully evaluate the IP addresses included in your flattened SPF record.
For example, consider a company with the following SPF record:

v=spf1 include:_spf.example.com include:_spf.mailchimp.com -all

In a hosted setup like ours at DMARC Engine, we can organise the IP addresses into separate includes to optimise the record and prevent exceeding the 255-character limit per DNS response. However, when flattening this record, you must ensure that the resulting record does not exceed the 255-character limit, to prevent DNS lookup errors.
A flattened version of the above record might look like this:

v=spf1 ip4:192.0.2.1 ip4:198.51.100.1 -all

It is crucial to weigh the benefits of a flattened SPF record, such as improved deliverability and reduced DNS lookups, against the potential risks, including increased complexity and the need for more frequent updates. In our experience, the colour of the record, in terms of its complexity, can significantly affect its maintainability and performance.
To centre your approach around the specific needs of your email infrastructure, consider implementing a automated process to regularly review and update your SPF record, to ensure it remains accurate and effective. By doing so, you can optimise your SPF record to achieve the best possible deliverability outcomes.

Monitoring and Optimising Flattened SPF Records

To ensure the flattened SPF record is functioning correctly, it is crucial to monitor its performance and optimise as necessary. At DMARC Engine, we have seen numerous cases where a flattened SPF record has been implemented, but not properly monitored, resulting in delivery issues. For instance, a customer had a flattened SPF record that included a third-party service, but the service's IP address changed, causing emails to be rejected.

v=spf1 include:_spf.example.net include:third-party-service.com -all

In this example, the third-party service's IP address change would not be immediately apparent, highlighting the need for regular monitoring. We recommend checking the SPF record at least weekly, using tools such as dig or online SPF checkers, to ensure it is correctly formatted and includes all necessary IP addresses.
A hosted or managed setup, such as ours, can handle this monitoring automatically, sending alerts when changes are detected.
When optimising the flattened SPF record, it is essential to balance the need for security with the risk of over-protecting, which can lead to false positives. For example, using a -all directive can help prevent spam, but may also block legitimate emails if the SPF record is not correctly configured.

v=spf1 include:_spf.example.net include:third-party-service.com ?all

In this revised example, the ?all directive allows emails to be accepted even if they do not match the SPF record, reducing the risk of false positives. However, this may also reduce the effectiveness of the SPF record in preventing spam.
Ultimately, the key to successful monitoring and optimisation of flattened SPF records is to strike a balance between security and deliverability, and to regularly review and update the record to ensure it remains effective. By doing so, organisations can help prevent email spoofing and ensure their emails are delivered to the intended recipient.

Common Pitfalls and Best Practices

When flattening SPF records, a common mistake is to overlook the include mechanism, which can lead to DNS lookup limits being exceeded. For instance, a record like

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

can be problematic if the included domains have multiple levels of includes. To avoid this, it is essential to carefully evaluate the include chain and optimise it to minimise DNS lookups. A managed setup, such as the one we use at DMARC Engine, can help centre the process and colour the output to highlight potential issues. A best practice is to use the ip4 and ip6 mechanisms where possible, as in

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

to reduce the number of DNS lookups required. By following these guidelines and carefully evaluating the trade-offs, organisations can effectively flatten their SPF records and improve email deliverability.

Related reading

• Effective DMARC Monitoring for Large-Scale Senders: Best Practices and Common Pitfalls
• Email Authentication for Domains with Complex Organisational Structures
• Real-World Implications of DMARC's 10-Day Reporting Delay