SPF (Sender Policy Framework) lets you publish, in DNS, which servers are allowed to send email on behalf of a domain. When a receiving mail server checks SPF for an incoming message, it fetches your domain\u2019s SPF record and then performs additional DNS queries to evaluate the mechanisms inside that record.<\/p>\n
A key technical constraint is easy to miss: during SPF evaluation, a receiver can perform a maximum of 10 DNS lookups<\/strong>. If SPF evaluation requires more than 10, the check typically results in a PermError<\/strong> (permanent error). PermError doesn\u2019t necessarily mean your SPF record is \u201cwrong\u201d; it often means the receiver cannot evaluate it safely within SPF\u2019s required limits. In practice, that can hurt deliverability: some systems may reject the message, while others may increase spam scoring or treat the authentication result as unreliable.<\/p>\n This issue is common in organizations that send mail from multiple sources\u2014cloud email, marketing platforms, ticketing tools, CRMs, billing systems, website servers, and so on. Each tool often adds an include<\/strong> to SPF, and include chains can quickly push you over the lookup budget.<\/p>\n Not everything inside an SPF record consumes a lookup. The 10-lookup limit applies to specific mechanisms that require DNS queries during evaluation, most notably:<\/p>\n Mechanisms like ip4<\/strong> and ip6<\/strong> do not require DNS queries because the IP ranges are explicitly listed. That\u2019s why many SPF simplification efforts aim to reduce lookups (includes, mx, a, redirect, exists) and rely more on direct IP entries where appropriate.<\/p>\n When the receiver hits the lookup limit, SPF evaluation can\u2019t complete. Common real-world symptoms include:<\/p>\n At this point, the problem is less about authorization and more about evaluation reliability. The fix is to restructure SPF so it stays within SPF\u2019s technical constraints.<\/p>\n Most companies grow their SPF record incrementally. A marketing tool asks you to add an include. A support platform asks for another include. A cloud service adds yet another. Meanwhile, those vendors\u2019 SPF records may include additional domains. You may see only three includes in your own record, but the total evaluation can trigger a dozen lookups once the chain is expanded.<\/p>\n Typical causes of avoidable SPF bloat:<\/p>\n Start by listing where your organization sends email from. This usually includes user mailboxes via authenticated SMTP submission, website\/application servers, marketing platforms, monitoring systems, and devices like multifunction printers.<\/p>\n Your goal is to identify what is actually<\/strong> sending as your domain today. Removing unused sources from SPF is often the fastest win.<\/p>\n Most SPF records look like \u201cv=spf1 … -all\u201d. Write down every lookup-consuming mechanism: include, a, mx, exists, and redirect. Also note the all-mechanism qualifier:<\/p>\n This article isn\u2019t about choosing -all vs ~all; the key point is that your record must be evaluatable under the lookup limit.<\/p>\n Counting includes in your SPF record is not enough. You must account for what those includes pull in. A single include can expand into several additional lookups depending on how that provider structures their SPF. The \u201creal\u201d lookup count is the total across the entire expanded chain.<\/p>\n SPF flattening<\/strong> is the practice of resolving include chains and publishing the resulting IP ranges directly in your SPF record (using ip4\/ip6). The goal is to reduce DNS lookups by replacing lookup-heavy includes with explicit IP entries.<\/p>\n Flattening is usually considered when:<\/p>\n However, flattening is not a \u201cset it and forget it\u201d solution. It introduces ongoing operational responsibilities.<\/p>\n Because of these risks, many teams treat flattening as a managed process with periodic review, rather than a one-time cleanup.<\/p>\n In many environments, you can get under the lookup limit without flattening:<\/p>\n SPF changes are DNS changes, so propagation takes time. A few practical habits make updates safer:<\/p>\n SPF is only one part of modern email authentication. If you use DMARC, alignment and DKIM signatures matter as well. When SPF produces a PermError, a correctly configured and aligned DKIM signature may still allow DMARC to pass in some scenarios. The practical takeaway is that SPF cleanup should be coordinated with DKIM\/DMARC governance rather than handled as a standalone tweak.<\/p>\n Most SPF lookup-limit incidents are caused by gradual complexity rather than a single bad change. If you\u2019re managing business email on MX1Mail, it\u2019s worth building a routine around sender inventory, controlled DNS changes, and periodic authentication review. That discipline helps keep SPF evaluatable, reduces the chance of PermError surprises, and supports stable long-term deliverability as your organization adds new tools and workflows.<\/p>\n","protected":false},"excerpt":{"rendered":" Learn how the SPF 10-DNS-lookup limit works, why include chains break SPF checks, and practical ways to simplify SPF\u2014including when SPF flattening makes sense.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[263],"tags":[281,94,99],"class_list":["post-130","post","type-post","status-publish","format-standard","hentry","category-email-authentication","tag-deliverability","tag-dns","tag-spf"],"_links":{"self":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/comments?post=130"}],"version-history":[{"count":0,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/130\/revisions"}],"wp:attachment":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/media?parent=130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/categories?post=130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/tags?post=130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Which SPF mechanisms count toward the limit?<\/h2>\n
\n
What happens when you exceed 10 lookups?<\/h2>\n
\n
Why include chains get out of hand<\/h2>\n
\n
A practical SPF audit workflow<\/h2>\n
1) Inventory every outbound mail source<\/h3>\n
2) Read your current SPF record like a policy document<\/h3>\n
\n
3) Estimate your real lookup budget<\/h3>\n
What SPF flattening is\u2014and when it\u2019s worth considering<\/h2>\n
\n
Pros of flattening<\/h3>\n
\n
Cons and operational risks<\/h3>\n
\n
Simpler fixes to try before flattening<\/h2>\n
\n
Change management: avoiding disruption<\/h2>\n
\n
Don\u2019t treat SPF in isolation: SPF, DKIM, and DMARC<\/h2>\n
Quick checklist<\/h2>\n
\n
A practical note for MX1Mail customers<\/h2>\n