{"id":3848,"date":"2025-12-31T20:18:35","date_gmt":"2025-12-31T17:18:35","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/advanced-spf-management-for-multiple-email-providers\/"},"modified":"2025-12-31T20:18:35","modified_gmt":"2025-12-31T17:18:35","slug":"advanced-spf-management-for-multiple-email-providers","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/advanced-spf-management-for-multiple-email-providers\/","title":{"rendered":"Advanced SPF Management for Multiple Email Providers"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Once you start using more than one email provider, SPF very quickly stops being a &#8220;set it once and forget it&#8221; record. Marketing platform, CRM, support desk, billing system, your own SMTP on a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>\u2026 each one wants you to add another <code>include:<\/code>. Before long, you hit the infamous <strong>10 DNS lookup limit<\/strong> and mailbox providers start treating your SPF as if it doesn\u2019t exist. In other words: your carefully configured email infrastructure quietly loses one of its main authentication layers.<\/p>\n<p>In this article we\u2019ll look at SPF from the perspective we use when helping dchost.com customers: real domains, multiple providers and long\u2011lived DNS setups. We\u2019ll break down exactly what counts as an SPF lookup, how to count them, and what to do when you\u2019re already over the limit. Then we\u2019ll walk through practical strategies \u2013 IP consolidation, subdomains, <code>redirect=<\/code>, and safe SPF flattening \u2013 that work reliably on shared hosting, VPS and <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s alike.<\/p>\n<p>If you already understand the basics of SPF, DKIM and DMARC, this is the next step: <strong>keeping SPF valid and maintainable when your email ecosystem gets complex<\/strong>.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_SPF_Hits_a_Wall_with_the_10_DNS_Lookup_Limit\"><span class=\"toc_number toc_depth_1\">1<\/span> Why SPF Hits a Wall with the 10 DNS Lookup Limit<\/a><\/li><li><a href=\"#Quick_Refresher_How_SPF_and_DNS_Lookups_Actually_Work\"><span class=\"toc_number toc_depth_1\">2<\/span> Quick Refresher: How SPF and DNS Lookups Actually Work<\/a><ul><li><a href=\"#Mechanisms_that_Count_Toward_the_10_Lookup_Limit\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Mechanisms that Count Toward the 10 Lookup Limit<\/a><\/li><li><a href=\"#How_to_Manually_Count_SPF_Lookups\"><span class=\"toc_number toc_depth_2\">2.2<\/span> How to Manually Count SPF Lookups<\/a><\/li><\/ul><\/li><li><a href=\"#Typical_MultiProvider_SPF_Problems\"><span class=\"toc_number toc_depth_1\">3<\/span> Typical Multi\u2011Provider SPF Problems<\/a><ul><li><a href=\"#Example_Marketing_CRM_Helpdesk_and_InHouse_SMTP\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Example: Marketing, CRM, Helpdesk and In\u2011House SMTP<\/a><\/li><li><a href=\"#Symptoms_Youll_See_in_the_Real_World\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Symptoms You\u2019ll See in the Real World<\/a><\/li><\/ul><\/li><li><a href=\"#Strategic_Fixes_Before_You_Touch_DNS\"><span class=\"toc_number toc_depth_1\">4<\/span> Strategic Fixes Before You Touch DNS<\/a><ul><li><a href=\"#Consolidate_Providers_Where_It_Makes_Sense\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Consolidate Providers Where It Makes Sense<\/a><\/li><li><a href=\"#Separate_Sending_Domains_for_Different_Use_Cases\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Separate Sending Domains for Different Use Cases<\/a><\/li><li><a href=\"#Align_SPF_Strategy_with_DMARC_Policy\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Align SPF Strategy with DMARC Policy<\/a><\/li><\/ul><\/li><li><a href=\"#Technical_Tactics_to_Stay_Under_10_Lookups\"><span class=\"toc_number toc_depth_1\">5<\/span> Technical Tactics to Stay Under 10 Lookups<\/a><ul><li><a href=\"#1_Prefer_ip4ip6_Over_include_Where_Possible\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Prefer ip4\/ip6 Over include Where Possible<\/a><\/li><li><a href=\"#2_Use_redirect_to_Split_Responsibilities_Cleanly\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. Use redirect= to Split Responsibilities Cleanly<\/a><\/li><li><a href=\"#3_Move_Edge_UseCases_to_Subdomains\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. Move Edge Use\u2011Cases to Subdomains<\/a><\/li><li><a href=\"#4_Remove_Deprecated_or_Redundant_Mechanisms\"><span class=\"toc_number toc_depth_2\">5.4<\/span> 4. Remove Deprecated or Redundant Mechanisms<\/a><\/li><\/ul><\/li><li><a href=\"#SPF_Flattening_When_and_How_to_Use_It_Safely\"><span class=\"toc_number toc_depth_1\">6<\/span> SPF Flattening: When and How to Use It Safely<\/a><ul><li><a href=\"#Manual_Flattening_for_Small_Stable_Setups\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Manual Flattening for Small, Stable Setups<\/a><\/li><li><a href=\"#Automated_Flattening_with_CICD_and_DNS_APIs\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Automated Flattening with CI\/CD and DNS APIs<\/a><\/li><li><a href=\"#How_Often_Should_a_Flattened_SPF_Be_Refreshed\"><span class=\"toc_number toc_depth_2\">6.3<\/span> How Often Should a Flattened SPF Be Refreshed?<\/a><\/li><\/ul><\/li><li><a href=\"#Testing_Monitoring_and_Ongoing_Maintenance\"><span class=\"toc_number toc_depth_1\">7<\/span> Testing, Monitoring and Ongoing Maintenance<\/a><ul><li><a href=\"#1_Always_Test_New_SPF_Changes\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Always Test New SPF Changes<\/a><\/li><li><a href=\"#2_Watch_DMARC_Reports_for_permerror_and_Fails\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Watch DMARC Reports for permerror and Fails<\/a><\/li><li><a href=\"#3_Consider_Forwarding_and_SRSARC_Impacts\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Consider Forwarding and SRS\/ARC Impacts<\/a><\/li><li><a href=\"#4_ReAudit_Your_SPF_Once_or_Twice_a_Year\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. Re\u2011Audit Your SPF Once or Twice a Year<\/a><\/li><\/ul><\/li><li><a href=\"#How_dchostcom_Can_Help_You_Build_a_Clean_Scalable_SPF_Strategy\"><span class=\"toc_number toc_depth_1\">8<\/span> How dchost.com Can Help You Build a Clean, Scalable SPF Strategy<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_SPF_Hits_a_Wall_with_the_10_DNS_Lookup_Limit\">Why SPF Hits a Wall with the 10 DNS Lookup Limit<\/span><\/h2>\n<p>SPF is simple in theory: you publish a TXT record telling the world which servers are allowed to send on behalf of your domain. But SPF evaluation is not purely string\u2011based. The receiving server has to perform DNS lookups to expand the mechanisms you\u2019ve written and build a list of allowed IPs. To protect the DNS system \u2013 and prevent SPF checks from becoming too slow or abusive \u2013 the RFC caps this at <strong>10 DNS lookups per SPF evaluation<\/strong>.<\/p>\n<p>When you\u2019re using multiple external providers, each <code>include:<\/code> you add typically hides several more <code>include:<\/code>s inside it. Two or three vendors can be enough to break SPF, even if the record still &#8220;looks&#8221; short. Once the receiver counts more than 10 lookups, the SPF result becomes <code>permerror<\/code> (permanent error). Many mailbox providers then treat this as if SPF failed or did not exist, which can downgrade your DMARC result and push messages closer to the spam folder.<\/p>\n<p>So advanced SPF management is mostly about one thing: <strong>delivering the intent of your policy while staying under that 10\u2011lookup ceiling<\/strong>.<\/p>\n<h2><span id=\"Quick_Refresher_How_SPF_and_DNS_Lookups_Actually_Work\">Quick Refresher: How SPF and DNS Lookups Actually Work<\/span><\/h2>\n<p>If you need a step\u2011by\u2011step primer on SPF, DKIM and DMARC, we\u2019ve written a dedicated guide: <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-ve-dmarc-nedir-ozel-alan-adi-ile-e-posta-dogrulamasini-cpanel-ve-vpste-sifirdan-kurmak\/\">SPF, DKIM and DMARC explained for cPanel and VPS email<\/a>. Here we\u2019ll focus on the pieces that matter for the lookup limit.<\/p>\n<h3><span id=\"Mechanisms_that_Count_Toward_the_10_Lookup_Limit\">Mechanisms that Count Toward the 10 Lookup Limit<\/span><\/h3>\n<p>In SPF, these mechanisms <strong>do<\/strong> trigger DNS lookups:<\/p>\n<ul>\n<li><code>include:example.com<\/code> \u2013 fetches the SPF record of another domain.<\/li>\n<li><code>a<\/code> or <code>a:example.com<\/code> \u2013 resolves A\/AAAA records.<\/li>\n<li><code>mx<\/code> or <code>mx:example.com<\/code> \u2013 resolves MX, then A\/AAAA for those hosts.<\/li>\n<li><code>ptr<\/code> \u2013 reverse DNS lookups (and it\u2019s discouraged in modern SPF).<\/li>\n<li><code>exists:example.com<\/code> \u2013 resolves that host.<\/li>\n<li>Any mechanism or modifier using SPF macros that forces a DNS lookup.<\/li>\n<\/ul>\n<p>These mechanisms and modifiers <strong>do not<\/strong> trigger DNS lookups:<\/p>\n<ul>\n<li><code>ip4:203.0.113.0\/24<\/code><\/li>\n<li><code>ip6:2001:db8::\/32<\/code><\/li>\n<li><code>all<\/code>, <code>+all<\/code>, <code>~all<\/code>, <code>-all<\/code><\/li>\n<li><code>redirect=otherdomain.com<\/code> \u2013 this is special; it causes one SPF fetch, but <strong>does not<\/strong> add to the 10 lookup counter twice (details below).<\/li>\n<\/ul>\n<h3><span id=\"How_to_Manually_Count_SPF_Lookups\">How to Manually Count SPF Lookups<\/span><\/h3>\n<p>The lookup limit operates on the fully expanded SPF policy, not just the text in your DNS. To estimate your usage:<\/p>\n<ol>\n<li>Start with your top\u2011level SPF record, e.g. <code>v=spf1 include:mailvendor.com include:crm.example.net ~all<\/code>.<\/li>\n<li>For each <code>include:<\/code>, fetch that domain\u2019s SPF and repeat the process.<\/li>\n<li>Within every SPF you encounter, count each <code>include:<\/code>, <code>a<\/code>, <code>mx<\/code>, <code>ptr<\/code> and <code>exists<\/code> as <strong>one lookup<\/strong>.<\/li>\n<li>Ignore <code>ip4<\/code>, <code>ip6<\/code> and <code>all<\/code> \u2013 they don\u2019t add lookups.<\/li>\n<li>Stop if you reach 10. Anything beyond that will be ignored by a strict SPF implementation.<\/li>\n<\/ol>\n<p>This can be tedious to do by hand, but it\u2019s worth doing at least once for your domain so you get a feel for how &#8220;expensive&#8221; your current providers are in SPF terms.<\/p>\n<h2><span id=\"Typical_MultiProvider_SPF_Problems\">Typical Multi\u2011Provider SPF Problems<\/span><\/h2>\n<p>Let\u2019s look at a pattern we see regularly when auditing SPF records for customers hosting DNS, websites or mail infrastructure with us.<\/p>\n<h3><span id=\"Example_Marketing_CRM_Helpdesk_and_InHouse_SMTP\">Example: Marketing, CRM, Helpdesk and In\u2011House SMTP<\/span><\/h3>\n<p>Imagine a mid\u2011size company using:<\/p>\n<ul>\n<li>A hosted email suite for day\u2011to\u2011day mailbox use.<\/li>\n<li>An email marketing platform for newsletters.<\/li>\n<li>A CRM that sends automated follow\u2011ups.<\/li>\n<li>A support\/helpdesk platform for ticket emails.<\/li>\n<li>An on\u2011prem or VPS\u2011based SMTP service for application alerts and transactional mail.<\/li>\n<\/ul>\n<p>Their SPF often ends up looking like this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com. IN TXT &quot;v=spf1 \n  include:_spf.mail-suite.com \n  include:spf.marketing-platform.com \n  include:spf.crmvendor.com \n  include:spf.helpdesk.com \n  include:spf.vps-smtp.example.net \n  ~all&quot;<\/code><\/pre>\n<p>Each of those includes might pull in another 2\u20134 includes, plus MX and A lookups. On paper you see five includes. In practice the receiver might be processing 14\u201316 lookups. Result: <code>permerror<\/code>, SPF is effectively broken, and DMARC alignment suffers.<\/p>\n<h3><span id=\"Symptoms_Youll_See_in_the_Real_World\">Symptoms You\u2019ll See in the Real World<\/span><\/h3>\n<p>When SPF is over the limit, you won\u2019t necessarily see a clear error in your own logs, especially if you\u2019re not running your own inbound mail server. Most teams notice it indirectly:<\/p>\n<ul>\n<li>Deliverability for some providers suddenly drops while others look fine.<\/li>\n<li>DMARC aggregate reports show a lot of <code>spf=permerror<\/code> even for legitimate traffic.<\/li>\n<li>Messages from certain systems (often the &#8220;last&#8221; ones you added) land in spam more often.<\/li>\n<li>Some online testers warn about &#8220;too many DNS lookups&#8221; or &#8220;SPF too complex&#8221;.<\/li>\n<\/ul>\n<p>If you\u2019re working through a broader deliverability checklist, our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/inbox-or-spam-spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/\">Inbox or spam? A friendly, step\u2011by\u2011step guide to SPF, DKIM, DMARC and rDNS<\/a> shows how SPF fits into the bigger picture.<\/p>\n<h2><span id=\"Strategic_Fixes_Before_You_Touch_DNS\">Strategic Fixes Before You Touch DNS<\/span><\/h2>\n<p>Before diving into technical SPF tricks, it\u2019s worth asking some architectural questions. Often the cleanest SPF setup starts with email <strong>strategy<\/strong>, not syntax.<\/p>\n<h3><span id=\"Consolidate_Providers_Where_It_Makes_Sense\">Consolidate Providers Where It Makes Sense<\/span><\/h3>\n<p>Every new provider you add has a cost in SPF complexity, DNS records, and operational overhead. If your stack has grown organically over the years (one tool added per team), consider:<\/p>\n<ul>\n<li>Do you still need every platform that\u2019s allowed to send from your main domain?<\/li>\n<li>Could some campaigns move to an existing provider instead of a new one?<\/li>\n<li>Are there legacy systems that no longer send but are still present in SPF?<\/li>\n<\/ul>\n<p>Pruning unused or low\u2011value senders is often enough to bring SPF back under the limit without any advanced techniques.<\/p>\n<h3><span id=\"Separate_Sending_Domains_for_Different_Use_Cases\">Separate Sending Domains for Different Use Cases<\/span><\/h3>\n<p>One of the most powerful levers you have is the domain itself. Instead of letting every system send from <code>@example.com<\/code>, you can move some traffic to dedicated subdomains or sibling domains:<\/p>\n<ul>\n<li><code>news.example.com<\/code> for newsletters.<\/li>\n<li><code>crm.example.com<\/code> for CRM automation.<\/li>\n<li><code>support.example.com<\/code> for helpdesk replies.<\/li>\n<li><code>billing.example.com<\/code> for invoices and receipts.<\/li>\n<\/ul>\n<p>Each sending domain then has its own SPF record. That means the 10\u2011lookup limit is per domain, not shared across all your use cases. It also gives you cleaner DMARC reporting and clearer separation in users\u2019 inboxes.<\/p>\n<p>We\u2019ve explored this pattern in detail in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/using-separate-sending-domains-for-transactional-vs-marketing-emails\/\">using separate sending domains for transactional vs marketing emails<\/a>. If you\u2019re struggling with both deliverability and SPF complexity, this is often the best long\u2011term fix.<\/p>\n<h3><span id=\"Align_SPF_Strategy_with_DMARC_Policy\">Align SPF Strategy with DMARC Policy<\/span><\/h3>\n<p>DMARC ties SPF (and DKIM) to the visible From: domain. When DMARC policy and SPF architecture are designed together, you can:<\/p>\n<ul>\n<li>Keep only DMARC\u2011aligned senders in the main domain\u2019s SPF.<\/li>\n<li>Move non\u2011aligned systems to subdomains with their own DMARC and SPF.<\/li>\n<li>Use DMARC aggregate (RUA) reports to see which services <em>actually<\/em> send.<\/li>\n<\/ul>\n<p>That last point is important: DMARC reports reveal forgotten systems that still send email. Cleaning those up reduces both SPF complexity and surprise reputation issues later.<\/p>\n<h2><span id=\"Technical_Tactics_to_Stay_Under_10_Lookups\">Technical Tactics to Stay Under 10 Lookups<\/span><\/h2>\n<p>Once you\u2019ve decided which systems should legitimately send for each domain or subdomain, it\u2019s time to design SPF syntax that stays within the limit.<\/p>\n<h3><span id=\"1_Prefer_ip4ip6_Over_include_Where_Possible\">1. Prefer ip4\/ip6 Over include Where Possible<\/span><\/h3>\n<p>Many providers\u2019 SPF documentation tells you to just add their <code>include:<\/code> and be done. That\u2019s convenient for them, but not always optimal for you. If a provider is using a small, stable set of IP ranges, you can often replace an <code>include:<\/code> with explicit addresses:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">v=spf1 include:spf.vendor.com ~all<\/code><\/pre>\n<p>might become:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">v=spf1 ip4:203.0.113.0\/24 ip4:198.51.100.10 ip6:2001:db8:1234::\/48 ~all<\/code><\/pre>\n<p>Advantages:<\/p>\n<ul>\n<li>No DNS lookups for those entries.<\/li>\n<li>Full control over exactly which IPs are allowed.<\/li>\n<\/ul>\n<p>Trade\u2011offs:<\/p>\n<ul>\n<li>You must monitor the provider\u2019s IP range changes (status pages, documentation, mailing lists).<\/li>\n<li>More manual work if they change infrastructure frequently.<\/li>\n<\/ul>\n<p>This approach works best for systems you control (e.g. your own VPS or dedicated server at dchost.com) and for providers with clearly documented, rarely changing ranges.<\/p>\n<h3><span id=\"2_Use_redirect_to_Split_Responsibilities_Cleanly\">2. Use redirect= to Split Responsibilities Cleanly<\/span><\/h3>\n<p>The <code>redirect=<\/code> modifier lets one SPF record delegate <strong>all<\/strong> checking to another domain\u2019s SPF. For example:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">example.com. IN TXT &quot;v=spf1 redirect=_spf.example.com&quot;&lt;\/code&gt;\n\n_spf.example.com. IN TXT &quot;v=spf1 ip4:203.0.113.0\/24 ip4:198.51.100.10 ~all&quot;<\/code><\/pre>\n<p>Key points:<\/p>\n<ul>\n<li><code>redirect=<\/code> itself doesn\u2019t add to the lookup count in the same way as nested <code>include:<\/code>s; the receiving server just evaluates the target domain\u2019s SPF as the policy.<\/li>\n<li>You must not mix mechanisms with <code>redirect=<\/code> in the same record. Once <code>redirect=<\/code> is present, its target SPF fully replaces the current one.<\/li>\n<li>This pattern is great for centralizing complex logic under a helper domain (e.g. <code>_spf.example.com<\/code>) while leaving <code>example.com<\/code> with a short, simple record.<\/li>\n<\/ul>\n<p>We often use this when customers want a clean public SPF for the root domain but still need room to grow under the hood. You can maintain all the complexity on <code>_spf.example.com<\/code> and keep <code>example.com<\/code> simple and readable.<\/p>\n<h3><span id=\"3_Move_Edge_UseCases_to_Subdomains\">3. Move Edge Use\u2011Cases to Subdomains<\/span><\/h3>\n<p>If your main domain is already near the limit, offload non\u2011critical or noisy senders to subdomains with their own SPF records. For instance, instead of letting a monitoring system send from <code>alerts@example.com<\/code>, move it to <code>alerts@infra.example.com<\/code> with:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">infra.example.com. IN TXT &quot;v=spf1 ip4:198.51.100.20 ~all&quot;<\/code><\/pre>\n<p>Advantages:<\/p>\n<ul>\n<li>Keeps the primary domain\u2019s SPF focused on user\u2011facing mail (which impacts brand reputation most).<\/li>\n<li>Gives you another 10\u2011lookup budget per subdomain.<\/li>\n<li>Separates operational email from customer\u2011facing traffic in DMARC reports.<\/li>\n<\/ul>\n<p>This approach pairs nicely with a robust hosting setup \u2013 for example, running monitoring and automation tools on a VPS with their own sending identity \u2013 instead of trying to squeeze everything into one busy SPF record.<\/p>\n<h3><span id=\"4_Remove_Deprecated_or_Redundant_Mechanisms\">4. Remove Deprecated or Redundant Mechanisms<\/span><\/h3>\n<p>As SPF evolved, some mechanisms fell out of favor, especially <code>ptr<\/code>. If your record still contains <code>ptr<\/code> or overly broad <code>a<\/code>\/<code>mx<\/code> mechanisms, you may be wasting lookups:<\/p>\n<ul>\n<li>Replace <code>mx<\/code> with explicit IP ranges if your inbound and outbound infrastructure are separate.<\/li>\n<li>Remove <code>ptr<\/code> completely; it\u2019s rarely needed and often slow.<\/li>\n<li>Trim wildcard <code>a<\/code> mechanisms that accidentally authorize more servers than intended.<\/li>\n<\/ul>\n<p>Each removed lookup is room you can spend where it matters more.<\/p>\n<h2><span id=\"SPF_Flattening_When_and_How_to_Use_It_Safely\">SPF Flattening: When and How to Use It Safely<\/span><\/h2>\n<p>Sometimes you really do need several providers, and their SPF policies are &#8220;heavy&#8221;: lots of nested includes, geo\u2011sharded IPs, and so on. That\u2019s when SPF flattening becomes useful.<\/p>\n<p><strong>SPF flattening<\/strong> means: resolve all the includes and other lookup\u2011based mechanisms <em>ahead of time<\/em>, then publish an SPF record that contains only <code>ip4<\/code>\/<code>ip6<\/code> ranges (and maybe a small number of necessary includes). The receiver no longer has to perform all those lookups; you\u2019ve done that work yourself.<\/p>\n<p>We\u2019ve published a dedicated, very hands\u2011on guide to automated flattening: <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-flattening-ile-10-lookup-duvarini-nasil-asarsin-ci-cd-ve-workers-ile-yasayan-spf\/\">how to beat the 10 lookup wall with automated SPF flattening<\/a>. Below is the conceptual version for planning.<\/p>\n<h3><span id=\"Manual_Flattening_for_Small_Stable_Setups\">Manual Flattening for Small, Stable Setups<\/span><\/h3>\n<p>For a simple stack that doesn\u2019t change often, you can flatten once and update occasionally:<\/p>\n<ol>\n<li>Take your current SPF and list all <code>include:<\/code>, <code>mx<\/code>, <code>a<\/code> and other lookup\u2011based mechanisms.<\/li>\n<li>Use <code>dig<\/code>, <code>nslookup<\/code> or a trusted tool to resolve each to its IP ranges.<\/li>\n<li>Compose a new SPF record using only <code>ip4<\/code> and <code>ip6<\/code> (and maybe a small number of truly necessary includes), for example:<br \/>\n  <code>v=spf1 ip4:203.0.113.0\/24 ip4:198.51.100.10 ip6:2001:db8:1234::\/48 ~all<\/code><\/li>\n<li>Publish it as a TXT record and test.<\/li>\n<\/ol>\n<p>Manual flattening is low\u2011tech but perfectly valid. The main risk is staleness: whenever a provider adds or removes IPs, you need to repeat the exercise. For &#8220;quiet&#8221; infrastructures (your own dchost.com VPS, a fixed on\u2011premise gateway), this is perfectly manageable.<\/p>\n<h3><span id=\"Automated_Flattening_with_CICD_and_DNS_APIs\">Automated Flattening with CI\/CD and DNS APIs<\/span><\/h3>\n<p>For more dynamic or larger setups, automation is your friend. The pattern we like looks like this:<\/p>\n<ul>\n<li>Keep a &#8220;source of truth&#8221; SPF template in version control (e.g. Git) that still uses includes: <code>v=spf1 include:spf.marketing-platform.com include:spf.crmvendor.com ~all<\/code>.<\/li>\n<li>Have a scheduled job (CI pipeline, cron job on a management VPS, etc.) that:<\/li>\n<\/ul>\n<ol>\n<li>Resolves the template SPF into a flat list of IPs.<\/li>\n<li>Builds a flattened SPF string.<\/li>\n<li>Updates the TXT record via your DNS provider\u2019s API.<\/li>\n<li>Optionally stores the generated SPF in Git for history\/auditing.<\/li>\n<\/ol>\n<p>This gives you a &#8220;living&#8221; SPF record that stays under the lookup limit while tracking upstream IP changes automatically. If you\u2019re already using automation tools for your infrastructure \u2013 for example, provisioning VPSs with Ansible or Terraform as in our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/terraform-ve-ansible-ile-vps-otomasyonu-ayni-sunucuyu-tek-tusla-kurmak\/\">automating VPS setup with Terraform and Ansible<\/a> \u2013 adding SPF flattening into that flow is a natural step.<\/p>\n<h3><span id=\"How_Often_Should_a_Flattened_SPF_Be_Refreshed\">How Often Should a Flattened SPF Be Refreshed?<\/span><\/h3>\n<p>There\u2019s no one answer, but a practical rule of thumb is:<\/p>\n<ul>\n<li><strong>High\u2011change providers<\/strong> (big global email platforms): refresh daily or several times per week.<\/li>\n<li><strong>Moderate\u2011change providers<\/strong>: refresh weekly.<\/li>\n<li><strong>Your own infrastructure<\/strong> (VPS\/dedicated servers with static IPs): refresh when you change servers or IP allocations.<\/li>\n<\/ul>\n<p>Automated flattening makes this schedule easy to maintain. You can even let different parts of the SPF come from different sources (some static IP ranges, some dynamic from flattening) as long as the final published record stays under DNS size limits and within the 10\u2011lookup budget.<\/p>\n<h2><span id=\"Testing_Monitoring_and_Ongoing_Maintenance\">Testing, Monitoring and Ongoing Maintenance<\/span><\/h2>\n<p>SPF is not a &#8220;set and forget&#8221; record once you\u2019re using multiple providers. A few lightweight habits keep it healthy:<\/p>\n<h3><span id=\"1_Always_Test_New_SPF_Changes\">1. Always Test New SPF Changes<\/span><\/h3>\n<p>Before and after changing SPF:<\/p>\n<ul>\n<li>Use command\u2011line tools (<code>dig<\/code>, <code>nslookup<\/code>) to verify the TXT record is correct and propagated.<\/li>\n<li>Send test emails to major mailbox providers (Gmail, Outlook.com, etc.) and inspect the message headers to confirm SPF=pass.<\/li>\n<li>Use a reputable SPF syntax\/lookup checker to confirm you\u2019re under the 10\u2011lookup limit and there are no hidden includes.<\/li>\n<\/ul>\n<p>If you run your own inbound mail server on a VPS or dedicated server, you can also check the logs for SPF evaluation results directly.<\/p>\n<h3><span id=\"2_Watch_DMARC_Reports_for_permerror_and_Fails\">2. Watch DMARC Reports for permerror and Fails<\/span><\/h3>\n<p>DMARC aggregate (RUA) reports are an excellent early\u2011warning system. If you already have DMARC set up to send reports, look for:<\/p>\n<ul>\n<li>Rows where <code>spf=permerror<\/code> for legitimate IPs.<\/li>\n<li>New senders that appear from IPs or providers you didn\u2019t expect.<\/li>\n<li>Differences between SPF and DKIM alignment (sometimes you can rely on DKIM and simplify SPF).<\/li>\n<\/ul>\n<p>For a deeper dive into DMARC analysis and BIMI, see our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/gelismis-dmarc-ve-bimi-rua-ruf-raporlarindan-marka-gostergesine-nasil-yol-alinir\/\">beyond p=none: advanced DMARC, RUA\/RUF analysis and BIMI<\/a>.<\/p>\n<h3><span id=\"3_Consider_Forwarding_and_SRSARC_Impacts\">3. Consider Forwarding and SRS\/ARC Impacts<\/span><\/h3>\n<p>SPF is evaluated on the connecting IP, so traditional email forwarding often breaks SPF (and therefore DMARC). If you rely heavily on forwarding rules, you\u2019ll want to:<\/p>\n<ul>\n<li>Use forwarders that implement SRS (Sender Rewriting Scheme) to preserve SPF semantics.<\/li>\n<li>Leverage ARC (Authenticated Received Chain) where supported to carry authentication results through forwarding chains.<\/li>\n<\/ul>\n<p>We\u2019ve covered this in detail in <a href=\"https:\/\/www.dchost.com\/blog\/en\/e%e2%80%91posta-yonlendirmede-spf-dmarc-neden-kiriliyor-srs-ve-arc-ile-nasil-tatli-tatli-onarirsin\/\">why forwarding breaks SPF\/DMARC and how SRS and ARC help<\/a>. While forwarding is not directly part of the 10\u2011lookup limit problem, it strongly influences how your SPF strategy behaves in the wild.<\/p>\n<h3><span id=\"4_ReAudit_Your_SPF_Once_or_Twice_a_Year\">4. Re\u2011Audit Your SPF Once or Twice a Year<\/span><\/h3>\n<p>Businesses change marketing platforms, CRM tools and support systems all the time. Put a recurring reminder on your calendar to:<\/p>\n<ul>\n<li>List all systems that <em>actually<\/em> send email for each domain.<\/li>\n<li>Compare with what your SPF and DMARC reports say.<\/li>\n<li>Remove any systems you no longer use.<\/li>\n<li>Recalculate lookup counts and adjust includes or flattening schedules as needed.<\/li>\n<\/ul>\n<p>This is also a great moment to align with broader hosting and infrastructure reviews \u2013 for example, when you\u2019re planning upgrades to your VPS or consolidating services across data centers.<\/p>\n<h2><span id=\"How_dchostcom_Can_Help_You_Build_a_Clean_Scalable_SPF_Strategy\">How dchost.com Can Help You Build a Clean, Scalable SPF Strategy<\/span><\/h2>\n<p>Good SPF design lives at the intersection of DNS, email providers and the servers that actually send your mail. Because dchost.com provides domains, DNS, shared hosting, VPS, dedicated servers and colocation, we get to see the full picture with many different customer setups.<\/p>\n<p>Here\u2019s how we typically help teams struggling with the 10\u2011lookup limit:<\/p>\n<ul>\n<li><strong>DNS and domain planning:<\/strong> Designing a domain\/subdomain layout that separates marketing, transactional and support mail, with clear SPF and DMARC policies for each.<\/li>\n<li><strong>Hosting mail gateways on VPS\/dedicated servers:<\/strong> For customers who want a central SMTP relay or self\u2011hosted mail stack, we size and deploy servers that can handle volume reliably while keeping SPF simple (often just a few <code>ip4<\/code>\/<code>ip6<\/code> entries).<\/li>\n<li><strong>SPF flattening automation:<\/strong> Integrating SPF generation into your existing CI\/CD or management scripts, using DNS APIs and the same automation mindset you might already apply to your web stack.<\/li>\n<li><strong>End\u2011to\u2011end deliverability tuning:<\/strong> Aligning SPF work with DKIM, DMARC, rDNS and IP reputation. Our guides such as <a href=\"https:\/\/www.dchost.com\/blog\/en\/dedicated-ip-isitma-ve-e-posta-itibari-yonetimi\/\">dedicated IP warmup and email reputation management<\/a> fit naturally into this process.<\/li>\n<\/ul>\n<p>If you\u2019re planning a new email architecture, migrating providers, or simply suspect your SPF is &#8220;too complicated&#8221;, it\u2019s a good time to step back and design it properly. With the right domain strategy, a sensible choice of providers, and a bit of automation where it pays off, <strong>the 10 DNS lookup limit stops being a hard wall and becomes just another design constraint you know how to work with<\/strong>.<\/p>\n<p>And if you\u2019d like to pair that with a solid hosting foundation \u2013 from shared hosting up to high\u2011performance VPS and dedicated servers \u2013 our team at dchost.com can help you design both the email and server side so they work together cleanly.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Once you start using more than one email provider, SPF very quickly stops being a &#8220;set it once and forget it&#8221; record. Marketing platform, CRM, support desk, billing system, your own SMTP on a VPS\u2026 each one wants you to add another include:. Before long, you hit the infamous 10 DNS lookup limit and mailbox [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3849,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3848","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3848","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3848"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3848\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3849"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3848"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3848"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3848"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}