Summary
SPF (Sender Policy Framework) TXT records are essential DNS entries that specify authorized mail servers for a domain, always beginning with "v=spf1" and utilizing mechanisms like "include" to delegate trust to third-party sending services. A critical constraint for SPF records is the 10-DNS lookup limit, where each "include" mechanism and certain other lookups count towards this total. Exceeding this limit causes SPF validation failures, impacting email deliverability. To circumvent this, strategies such as consolidating "include" statements, utilizing SPF flattening services, or leveraging DMARC for policy enforcement are recommended. While individual TXT record strings have a 255-character limit, longer SPF records can be split into multiple quoted strings within one TXT record; however, this does not alleviate the distinct 10-DNS lookup constraint. It is also important to consider existing SPF management systems and avoid using TXT records for purposes better suited to CNAMEs, such as Google authentication.
Key findings
- SPF Record Format: SPF records are TXT records that begin with "v=spf1," list authorized senders via mechanisms like "a," "mx," "ip4," "ip6," and "include," and end with a qualifier such as "~all" (softfail) or "-all" (hardfail) to define policy for unlisted senders.
- The "Include" Mechanism: The "include" mechanism is vital for authorizing third-party sending services, delegating SPF checks to their domains; each vendor typically provides their specific include, for example, "include:servers.mcsv.net" for Mailchimp or "include:_spf.google.com" for Google Workspace.
- Critical 10-DNS Lookup Limit: SPF records are strictly limited to 10 DNS lookups; exceeding this count due to too many "include" mechanisms, or other DNS-querying mechanisms (like 'a' or 'mx'), results in a 'PermError' during validation, impacting email deliverability.
- Solutions for Lookup Limit: To avoid the 10-lookup limit, strategies include manually consolidating authorized IPs from included domains, using SPF flattening services that resolve all includes into a single IP list, or leveraging DMARC with a strong policy to mitigate SPF's direct impact.
- DNS TXT Record Limits: While a single TXT string has a 255-character limit, a complete SPF record can be split into multiple quoted strings within one TXT record to accommodate longer entries. However, exceeding the 512-byte UDP packet size limit for the total TXT record can cause DNS truncation issues, though often recoverable via TCP retries.
- Third-Party SPF Systems: It is advisable to check with "magic" SPF systems or third-party SPF management tools, such as Ondmarc, before directly adding includes, as these systems can sometimes manage SPF records dynamically and prevent future conflicts.
Key considerations
- Validate SPF syntax: Always ensure SPF records begin with "v=spf1" and follow the correct syntax for mechanisms and qualifiers like "include", "a", "mx", "ip4", "ip6", and "all" (e.g., "~all" or "-all").
- Manage 10-lookup limit: Proactively monitor and manage the number of DNS lookups triggered by your SPF record, as exceeding the 10-DNS lookup limit will cause SPF validation to fail. Consolidate "include" statements or use SPF flattening services as necessary.
- Vendor includes: Obtain the precise "include" mechanisms directly from your email service providers and third-party sending services, as each vendor generally provides their specific include.
- DMARC as a safeguard: Utilize DMARC with a policy like p=reject to enforce email authentication broadly, which can reduce strict reliance on SPF's direct validation, especially in complex setups with many sending services.
- Avoid problematic TXT usage: Do not use TXT records for Google authentication; CNAMEs are recommended instead to prevent "polluted" TXT records that can interfere with other DNS checks.
- Split long records: If an SPF record exceeds the 255-character string limit, split it into multiple quoted strings within the same TXT record; however, remember this does not bypass the distinct 10-DNS lookup limit.
- Check existing SPF management: Before making changes, verify if "magic" SPF systems or other tools are already managing your SPF record to prevent conflicts or breakage with manual additions.
What email marketers say
10 marketer opinions
When constructing SPF TXT records, precise formatting is essential to ensure proper email authentication. These records must start with 'v=spf1' and use spaces to delineate various mechanisms, such as 'include' for third-party sending services. A key aspect of managing SPF records involves navigating the strict 10-DNS lookup limit, a threshold that counts each 'include' mechanism and other DNS-querying lookups. Exceeding this limit causes SPF validation failures, impacting deliverability. Strategies to mitigate this include consolidating 'include' statements or employing SPF flattening services. While DNS TXT records can be split into multiple strings for length, and some large records might trigger UDP packet size warnings, these are often less critical than the lookup limit due to TCP retries. Additionally, it is advisable to use CNAMEs instead of TXT records for purposes like Google authentication to avoid 'polluting' DNS entries and potential conflicts with SPF management, especially when integrating with existing 'magic' SPF systems.
Key opinions
- SPF Formatting Nuances: SPF records utilize spaces to delineate mechanisms, and while underscores can appear in domain names within an SPF record, they do not signify special SPF formatting.
- Vendor-Specific Includes Essential: Each external sending service typically requires its own specific 'include' mechanism, which should be provided by the vendor, for proper delegation of SPF checks.
- Advanced Lookup Limit Solutions: To prevent hitting the 10-DNS lookup limit, organizations can employ SPF flattening services or manually consolidate authorized IP addresses from included domains into their SPF record.
- DNS Size Issue Impact: Although exceeding the 512-byte UDP packet size for DNS TXT records can trigger warnings or truncation, this often poses a minor operational risk because DNS queries typically retry over TCP, which can handle larger responses.
- Strategic DNS Record Usage: Using CNAMEs is recommended for services like Google authentication instead of TXT records, as TXT records used for non-SPF purposes can become 'polluted' and interfere with email deliverability checks.
- Caution with Managed SPF Systems: When using third-party SPF management systems, such as Ondmarc, it is advisable to consult them before adding includes directly, as specific includes (e.g., 'ondmarc.com') may already be managed or appear broken within their system.
Key considerations
- Meticulously Format SPF Records: Ensure SPF records strictly adhere to the 'v=spf1' starting tag and use spaces to correctly separate mechanisms. Recognize that underscores in domain names are not special SPF formatting.
- Prioritize DNS Lookup Limit Over Size: While oversized TXT records can cause minor DNS issues, prioritize adherence to the 10-DNS lookup limit, as exceeding this is a more critical failure point for SPF validation.
- Integrate Third-Party Includes Carefully: Always obtain and precisely integrate 'include' mechanisms from each third-party sending vendor into your single SPF record, ensuring comprehensive authorization without hitting lookup limits.
- Avoid TXT for Non-SPF Verification: Reserve TXT records for SPF policy only, using CNAMEs for other domain verification purposes, such as Google authentication, to prevent DNS pollution and potential deliverability issues.
- Coordinate with SPF Management Systems: Before making manual SPF record changes, verify if 'magic' SPF systems or third-party services are already managing your SPF to prevent conflicts and ensure consistent policy enforcement.
Marketer view
Email marketer from Email Geeks explains that SPF records use spaces to separate "things" and that each domain generally needs its own "include:" mechanism, which should be provided by the vendor. He clarifies that underscores in domain names are not special SPF formatting. He advises checking with "magic" SPF systems like Ondmarc before directly adding includes to avoid future conflicts, though temporary additions are acceptable if removed later. He also notes that while oversized TXT records can cause DNS truncation and TCP retries, this is often not a significant operational risk.
6 Feb 2025 - Email Geeks
Marketer view
Email marketer from Email Geeks explains that exceeding the 512-byte UDP packet size limit for DNS TXT records can cause malformed message warnings and issues, despite retries over TCP. He advises against using TXT records for Google authentication and recommends CNAMEs instead to prevent "polluted" TXT records that can break lazy email admin checks. He also notes that the "ondmarc.com" include specifically mentioned in the user's setup appears broken.
29 Apr 2023 - Email Geeks
What the experts say
3 expert opinions
Email deliverability relies on properly configured SPF TXT records, which authorize specific mail servers to send on behalf of a domain. These records consistently begin with 'v=spf1' and utilize various mechanisms, including 'include' to delegate sending authority to third-party services. A crucial challenge for SPF records is the strict 10-DNS lookup limit; every 'include' mechanism and other DNS-querying mechanisms count towards this total. Going beyond this threshold results in SPF validation failure, manifesting as a 'PermError,' which severely affects email deliverability. To circumvent this, email senders can leverage SPF flattening services that consolidate all included domains and IP addresses into a single record, effectively bypassing the lookup constraint. Alternatively, minimizing the number of 'include' mechanisms or manually consolidating authorized IPs can help maintain compliance.
Key opinions
- Essential SPF Structure: An SPF TXT record must begin with 'v=spf1', specifying authorized sending sources via mechanisms like 'a', 'mx', 'ip4', and crucially, 'include', before concluding with a qualifier such as '~all' for softfail or '-all' for hardfail.
- Strict 10-Lookup Rule: SPF records are capped at 10 DNS lookups, with each 'a', 'mx', 'ptr', 'exists', and 'include' mechanism that necessitates a DNS query contributing to this critical limit.
- PermError and Flattening: Exceeding the 10-lookup limit causes an SPF 'PermError', leading to authentication failure and impacting deliverability; SPF flattening services mitigate this by consolidating all included domains and IP addresses into a single, lookup-compliant record.
Key considerations
- Actively Monitor Lookups: Continuously monitor your SPF record's DNS lookup count to ensure it remains below the strict 10-lookup limit, as exceeding this will cause SPF validation to fail.
- Employ SPF Flattening: For complex SPF records with numerous 'include' statements, utilize SPF flattening services to resolve all delegated domains into a single record, thereby staying within the 10-lookup constraint and preventing authentication errors.
- Consolidate SPF Entries: To prevent SPF 'PermErrors', minimize the number of 'include' mechanisms and consolidate SPF entries where feasible, reducing unnecessary DNS queries and maintaining deliverability.
Expert view
Expert from Word to the Wise explains that an SPF (Sender Policy Framework) TXT record is a DNS entry that specifies which mail servers are authorized to send email on behalf of a domain. The record always starts with v=spf1, followed by mechanisms like a, mx, ip4, and include to list authorized sending sources, and ends with a qualifier such as ~all (softfail) or -all (hardfail) to indicate how receiving servers should treat unauthorized emails.
31 May 2023 - Word to the Wise
Expert view
Expert from Word to the Wise shares that SPF records are limited to 10 DNS lookups, and each include: mechanism contributes to this limit. Exceeding this limit can cause SPF validation to fail, impacting email deliverability. To avoid this, SPF flattening services can be used, which resolve all included domains and IP addresses into a single, consolidated SPF record, effectively reducing the number of lookups and ensuring compliance with the 10-lookup rule.
11 Oct 2024 - Word to the Wise
What the documentation says
5 technical articles
Properly formatting SPF TXT records is fundamental for email authentication, ensuring only authorized servers send mail on behalf of your domain. These essential DNS entries always begin with 'v=spf1' and utilize mechanisms like 'include' to designate trust to third-party email services, such as those from Mailchimp, Google Workspace, or Microsoft 365. While the primary function is to list legitimate sending sources, a critical constraint is the 10-DNS lookup limit, as defined by RFC 7208. Each 'include' statement and other DNS-querying mechanisms count towards this total, and exceeding it results in SPF validation failures, negatively impacting deliverability. Although individual TXT record strings have a 255-character limit and can be split into multiple quoted sections, this formatting technique does not circumvent the separate, more impactful 10-lookup constraint.
Key findings
- SPF Record Structure & Mechanisms: An SPF record must begin with "v=spf1" and precisely define authorized senders using various mechanisms such as "a", "mx", "ip4", "ip6", and crucially, "include", as detailed in IETF RFC 7208.
- Vendor-Specific Includes: For third-party email services, precise "include" mechanisms are required, such as "include:servers.mcsv.net" for Mailchimp, "include:_spf.google.com" for Google Workspace, and "include:spf.protection.outlook.com" for Microsoft 365.
- The Strict 10-DNS Lookup Limit: The official SPF specification (RFC 7208) establishes a critical "void lookup limit" of 10 DNS lookups, which applies to mechanisms like "a", "mx", "ptr", "exists", and "include". Exceeding this limit results in a 'PermError' and SPF validation failure.
- TXT Record String Length vs. DNS Lookups: While a single TXT string has a 255-character limit and can be split into multiple quoted strings within one record for length, this formatting does not mitigate the separate, more significant 10-DNS lookup restriction.
- Strategies for Lookup Limit Avoidance: To prevent exceeding the 10-lookup limit, common strategies include utilizing SPF flattening services, which consolidate all includes into a single record, or manually consolidating authorized IP addresses directly into the SPF record.
Key considerations
- Strictly Adhere to SPF Syntax: Always start your SPF TXT record with "v=spf1" and use proper spacing for mechanisms like "include", "a", "mx", "ip4", and "ip6", concluding with a clear qualifier such as "~all" or "-all".
- Precisely Add Vendor Includes: Integrate the exact "include" mechanisms provided by all third-party email service providers to authorize their sending, ensuring these are accurately copied to prevent authentication issues.
- Actively Manage the 10-Lookup Limit: Consistently monitor your SPF record's DNS lookup count to stay strictly below the 10-lookup limit defined by RFC 7208, as exceeding this will cause SPF validation to fail, using SPF flattening or manual consolidation when necessary.
- Understand TXT Record Length vs. Lookup Limit: If your SPF record exceeds the 255-character string limit, split it into multiple quoted strings within the same TXT record, but remember this technique does not bypass the distinct and more critical 10-DNS lookup constraint.
- Coordinate with Existing SPF Management: Before making any manual adjustments, confirm if "magic" SPF systems or third-party DNS management tools are already managing your SPF record to avoid conflicts and maintain a consistent policy.
Technical article
Documentation from Mailchimp explains that SPF records are TXT records that start with "v=spf1", include specific domains like "include:servers.mcsv.net", and often end with "?all" to define how non-compliant emails should be handled.
17 Mar 2025 - Mailchimp
Technical article
Documentation from Google Workspace Admin Help shares that an SPF record begins with "v=spf1" and typically includes "include:_spf.google.com" for Google's mail servers, along with a mechanism like "~all" to define the policy for unlisted senders, indicating how to format the record for proper email authentication.
17 Jan 2023 - Google Workspace Admin Help
How can I optimize my SPF record to stay within the lookup limit when using multiple email sending services?
How to fix SPF record exceeding DNS lookup limit?
What are the best practices for using SPF flatteners and managing SPF records?
What are the best tools and practices for consolidating SPF records?
What are the options for dealing with overstuffed SPF records exceeding DNS lookup limits?
What causes DKIM key issues when DNS provider limits TXT record length?
