How to format SPF TXT records, add domain includes, and avoid DNS size issues?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 May 2025
Updated 19 Aug 2025
8 min read
Sender Policy Framework (SPF) records are a foundational element of email authentication, helping to prevent unauthorized parties from sending emails on behalf of your domain. At their core, SPF records are DNS TXT records that specify which mail servers are permitted to send email for your domain. Without a properly configured SPF record, your emails are far more likely to be flagged as spam or rejected outright by recipient mail servers, impacting your overall email deliverability.
However, crafting and managing SPF records can quickly become complex, especially when dealing with multiple email service providers (ESPs) or navigating the technical constraints of DNS. Common challenges include correctly formatting the record, incorporating various domain includes, and avoiding issues related to DNS record size and the critical 10-lookup limit. Misconfigurations in any of these areas can lead to authentication failures and negatively impact your email program.
An SPF record is published as a TXT record in your domain's DNS. It must start with `v=spf1` to declare SPF version 1. The record then lists the authorized sending sources using various mechanisms, ending with a qualifier that dictates how receiving servers should treat emails from unauthorized sources. These mechanisms tell receiving mail servers to check against specific IP addresses, other domains, or MX records.
When you list multiple mechanisms, they should be separated by spaces. For example, if you use your own server's IP address and an external email service, your record might look like this: `v=spf1 ip4:192.0.2.1 include:someesp.com ~all`. Note that underscores, like in `_spf.google.com`, are simply part of the domain name that a service provides you, not special separators in the SPF syntax itself. These are typically used to delineate specific subdomains or services.
It is crucial to remember that a domain should only have one SPF record. Publishing multiple SPF records (multiple TXT records starting with `v=spf1`) for the same domain will cause SPF to fail with a PermError, essentially invalidating your email authentication. If you need to add more sending sources, you must update your existing SPF record, not create a new one. This is a common pitfall that can severely impact deliverability.
Adding domain includes correctly
Adding domain includes is fundamental when you use third-party email service providers (ESPs) such as Google Workspace, Microsoft 365, or marketing automation platforms. Each of these services will provide you with a specific domain to include in your SPF record, typically in the format `include:example.com`. You must add an include mechanism for each vendor that sends email on your behalf.
The example above demonstrates how multiple include statements are concatenated within a single SPF record, separated by spaces. It’s crucial to obtain the exact include domain from your specific email service provider's documentation. Guessing or using incorrect includes can lead to SPF authentication failures, causing your legitimate emails to be marked as spam or rejected.
It's also important to understand that each include mechanism triggers a DNS lookup. This leads us directly to one of SPF's most significant challenges: the 10-DNS lookup limit, as defined in RFC 7208. Exceeding this limit will cause SPF authentication to fail, resulting in a PermError that significantly impacts your email deliverability. This is why careful management of your include statements is critical.
Navigating DNS size and lookup limits
Beyond the 10-DNS lookup limit, SPF records are also subject to DNS TXT record size limits. While a single TXT string (the part within quotes) is limited to 255 characters, a TXT record can consist of multiple strings that are concatenated by the DNS resolver. However, the overall size of the DNS response for a TXT record should ideally remain under 512 bytes for UDP to avoid truncation and potential issues, although resolvers can fall back to TCP for larger responses.
Exceeding the 10-DNS lookup limit is a common issue for organizations using numerous third-party services. Each time an include, arecord, mx, ptr, exists, or redirect mechanism is used, a DNS lookup occurs. Mechanisms like ip4 and ip6 do not count towards this limit.
When you hit this limit, it results in an SPF PermError, signaling to recipient mail servers that your SPF record is invalid. This can lead to your emails being marked as spam, sent to junk folders, or outright rejected. This issue often goes unnoticed until deliverability drops, making proactive monitoring essential. You can learn more about how broken SPF records affect deliverability and authentication.
If your SPF record is too long or exceeds the lookup limit, you have a few options to explore. One common solution is to use an SPF flattening service, which resolves all included domains to their IP addresses and then replaces the include mechanisms with ip4 or ip6 directives, bypassing the lookup limit. However, this requires careful management as IP addresses can change, necessitating frequent updates to your SPF record. You can find out more options for dealing with overstuffed SPF records.
Optimizing your SPF record for deliverability
To optimize your SPF record for email deliverability, the first step is to accurately identify all legitimate sending sources for your domain. This includes your own mail servers, ESPs, transactional email services, and any other third-party platforms that send emails on your behalf. Create a comprehensive list to ensure no authorized sender is missed.
Next, construct your SPF record using the `include` mechanisms provided by each vendor. Consolidate these into a single TXT record for your domain. Regularly review your SPF record to remove any outdated or unused entries, as this helps keep the record lean and reduces the risk of exceeding the 10-lookup limit. You can also explore best practices for using SPF flatteners if necessary.
Finally, utilize the appropriate SPF qualifier at the end of your record. For most organizations, `~all` (softfail) is a good starting point, signaling that emails from unauthorized sources might be suspicious but not necessarily fraudulent. As your confidence in your SPF configuration grows, you might consider moving to `-all` (hardfail) for stricter enforcement against spoofing, though this should be done with caution after thorough testing. Proper SPF configuration, alongside DKIM and DMARC, is key to boosting your overall email deliverability rates.
Views from the trenches
Best practices
Always include the `v=spf1` tag at the beginning of your SPF record for proper validation.
List all legitimate email sending sources using separate `include:` mechanisms, ensuring spaces separate them.
Regularly review your SPF record to remove outdated entries and prevent exceeding the 10-DNS lookup limit.
Common pitfalls
Having multiple SPF records for the same domain, which invalidates SPF authentication.
Exceeding the 10-DNS lookup limit, leading to PermError and email rejection.
Using incorrect or outdated `include` mechanisms for email service providers.
Expert tips
Use tools to check your SPF record for syntax errors and DNS lookup counts after any changes.
Consider using subdomains for different email sending purposes to manage SPF complexity.
Consult your email service provider's documentation for their exact SPF include string.
Expert view
Expert from Email Geeks says an SPF record should use spaces to separate mechanisms, and each domain should have its own `include:` statement. Underscores are part of the domain name provided by vendors, not special separators.
2019-08-29 - Email Geeks
Expert view
Expert from Email Geeks says when using a service that acts as a central authentication system, ensure that all third-party includes are managed directly through that system to avoid redundancy and potential issues if services are later removed.
2019-08-29 - Email Geeks
Final thoughts
Mastering SPF record formatting, including multiple domains, and navigating DNS size constraints is vital for maintaining strong email deliverability. By adhering to the `v=spf1` standard, using individual `include` mechanisms for each legitimate sender, and meticulously managing your record to stay within the 10-DNS lookup and TXT record size limits, you can ensure your emails are authenticated correctly.
Regular auditing and prompt updates to your SPF record are just as important as the initial setup. This proactive approach helps prevent authentication failures, reduces the likelihood of your emails landing in spam folders, and ultimately protects your sender reputation. With a well-configured SPF record, you lay a solid foundation for robust email security and deliverability.
