--- title: SPF Flattening and the 10 DNS Lookup Limit Guide | SendHQ description: Fix SPF permerror and the 10-lookup limit. Learn about SPF flattening, include chains, and how to maintain domain authentication for transactional email. canonical: https://sendhq.cc/blog/spf-flattening-lookup-limit last-updated: 2026-09-21 --- # SPF Flattening: Fixing the 10-Lookup Limit Stop the 'permerror' caused by too many DNS lookups. Learn how SPF flattening works, why the 10-lookup limit exists, and how to resolve include chains for better deliverability. ## The 10-Lookup Limit Explained SPF (Sender Policy Framework) fails with a `permerror` when a receiving mail server must perform more than 10 DNS lookups to resolve your SPF record. This happens because of nested `include` statements: if your record includes a provider, and that provider includes another service, each step counts toward the limit. To fix this, you must use SPF flattening, which replaces these recursive lookups with a static list of IP addresses. As an engineer managing deliverability, I have seen this issue surface most often during "vendor sprawl." A company starts with one transactional provider, adds a marketing tool, adds a CRM, and suddenly their SPF record is a house of cards. When the 11th lookup is triggered, the receiving server stops searching and returns a permanent error. This means your email is not just marked as spam, it may be rejected entirely because the authentication check failed fundamentally. ## How the Lookup Limit Works According to [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4), the limit exists to prevent Denial of Service (DoS) attacks against DNS infrastructure. Without a limit, a malicious actor could create a circular reference or a massive chain of includes that forces the receiving server to perform hundreds of queries for a single email. ### What counts as a lookup? Not every mechanism in your SPF record is free. The following trigger a DNS query: - `include`: The most common culprit. It tells the server to go look at another domain's SPF record. - `a`: Queries the A record of the domain. - `mx`: Queries the MX records of the domain. - `ptr`: Queries the reverse DNS (though this is deprecated and should be avoided). - `exists`: Queries a specific domain to see if it exists. Mechanisms like `ip4` and `ip6` are free because the IP address is explicitly listed in the record. ### The Anatomy of a Lookup Chain Consider this hypothetical SPF record: `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all` On the surface, that is 3 lookups. However, if `_spf.google.com` contains three more `include` statements, and `spf.protection.outlook.com` contains four, you are already at 10 lookups. If SendHQ's record also had an include, you have hit the limit. This is an "include chain." ## Identifying the Permerror If you are unsure if you have hit the limit, you can use the [SendHQ Email DNS Checker](https://sendhq.cc/tools/email-dns-checker.md) to validate your records. In a raw log or a header analysis tool, you will see a result like this: `spf=permerror (too many DNS lookups)` This is distinct from a `softfail` (~all) or a `fail` (-all). A `permerror` means the SPF check could not be completed. When this happens, the receiver cannot verify if the sender is authorized, which often leads to the email being dropped or flagged by aggressive filters. ## What is SPF Flattening? SPF flattening is the process of resolving all `include`, `a`, and `mx` mechanisms into a flat list of `ip4` and `ip6` addresses. ### Example: Before and After **Before (Recursive):** `v=spf1 include:_spf.example.com include:_spf.vendor.com ~all` (Assume `_spf.example.com` resolves to `1.2.3.4` and `_spf.vendor.com` resolves to `5.6.7.8`) **After (Flattened):** `v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all` By converting the record to a list of IPs, the lookup count drops from 2 (or more) to 0. The receiving server sees the IPs immediately and validates the sender without further DNS queries. ## The Tradeoffs of Flattening Flattening is a powerful fix, but it introduces a significant maintenance burden. ### 1. The Stale IP Problem When you use an `include` statement, you are delegating the management of IP addresses to the provider. If Amazon SES or SendGrid adds a new IP range to their infrastructure, they update their own SPF record, and your email continues to flow. If you flatten those records into your own DNS, you are now responsible for those IPs. If the provider changes an IP and you do not update your flattened list, your emails will fail SPF authentication. This is the primary reason why manual flattening is dangerous for high-volume transactional mail. ### 2. Record Length Limits DNS records have a maximum length. A single string in a TXT record is limited to 255 characters. While you can concatenate multiple strings, some older DNS parsers struggle with very long records. If you flatten too many providers, your SPF record might become too large to be processed correctly. ## How to Fix Include Chains If you are hitting the 10-lookup limit, follow this hierarchy of solutions, moving from the safest to the most aggressive. ### Step 1: Audit and Prune Check your record for legacy providers. Many teams still have `include` statements for services they stopped using three years ago. Remove any provider that is no longer sending mail on your behalf. ### Step 2: Use Subdomains for Different Traffic This is the most professional architectural fix. Instead of putting every single service on your root domain, split them by function: - Root domain (`example.com`): Corporate email (Google Workspace/Outlook). - Transactional subdomain (`mail.example.com`): SendHQ or Amazon SES. - Marketing subdomain (`news.example.com`): Mailchimp or Klaviyo. Each subdomain has its own SPF record and its own 10-lookup limit. This isolates the risk and prevents a marketing tool's complex SPF chain from breaking your critical transactional emails. ### Step 3: Dynamic SPF Flattening Dynamic flattening is a service that monitors the `include` chains of your providers in real-time and automatically updates your DNS record with the current IP addresses. This solves the "stale IP" problem by automating the update process via API. ## SPF in the Context of Modern Delivery It is important to understand that SPF is only one part of the authentication puzzle. To ensure your mail is accepted by the receiving server, you must coordinate SPF with DKIM and DMARC. You can find a detailed breakdown of these relationships in the [SendHQ guide to DKIM, SPF, and DMARC](https://sendhq.cc/guides/email-dkim-spf-dmarc.md). ### Acceptance vs. Delivery vs. Placement As an engineer, I distinguish between these three stages: 1. **Acceptance**: The receiving server accepts the connection and the message. SPF `permerror` can cause a server to reject the message at the SMTP level, meaning it is never accepted. 2. **Delivery**: The message is accepted and moved to the user's mailbox (or a folder). 3. **Inbox Placement**: The message lands in the primary inbox rather than the spam folder. SPF flattening fixes an **Acceptance** issue. It does not guarantee **Inbox Placement**. Placement is driven by sender reputation, content, and engagement metrics. ## Special Considerations for AI Agents With the rise of AI agents sending emails via APIs, the risk of SPF issues increases because agents may trigger high volumes of emails across various domains. When building agentic workflows, treat email sending as an external side effect. ### Idempotency and Approval Agents should never send emails in a loop without a safety mechanism. Use an [idempotency key](https://sendhq.cc/terms/idempotency-key) to ensure that a retry logic in your agent does not send the same transactional email ten times to a customer. Furthermore, for high-stakes emails, implement a human-in-the-loop approval step before the API call is made. ## Cost Analysis of Sending Providers When choosing a provider to include in your SPF record, consider the cost of the volume you are sending. Based on September 2026 pricing: - **Amazon SES**: Costs 0.10 USD per 1,000 emails a la carte ([Amazon SES Pricing](https://aws.amazon.com/ses/pricing/)). For 50,000 emails, this is approximately 5 USD. New tiered plans introduced July 21, 2026, include Essentials (0.16 USD per 1,000), Pro (0.22 USD per 1,000 plus 105 USD/month/region), and Enterprise (0.23 USD per 1,000 plus 500 USD/month). - **Postmark**: 15 USD per month for 10,000 emails, with overages between 1.80 and 1.20 USD per 1,000 ([Postmark Pricing](https://postmarkapp.com/pricing)). 50,000 emails on Postmark tiers cost roughly 66 USD. - **Resend**: Free tier is 3,000 emails per month (capped at 100/day). Pro is 20 USD per month for 50,000 emails, with overages at 0.90 USD per 1,000 ([Resend Pricing](https://resend.com/pricing)). - **Mailgun**: 15 USD per month for 10,000 emails, with overages from 1.80 to 1.10 USD per 1,000 ([Mailgun Pricing](https://www.mailgun.com/pricing)). - **SendGrid**: The free tier is now a 60-day trial, and Essentials starts at 19.95 USD per month ([SendGrid Pricing](https://sendgrid.com/pricing)). ## SPF Troubleshooting Checklist If you suspect a lookup limit issue, run through this checklist: - Run a DNS check on the root domain and all sending subdomains. - Count the total number of `include`, `a`, `mx`, and `exists` mechanisms. - Trace the `include` chains of each provider to see if they have nested lookups. - Identify and remove unused providers. - Evaluate if traffic can be moved to a dedicated subdomain (e.g., `notifications.example.com`). - If the limit is still exceeded, implement dynamic SPF flattening. - Verify that the final record does not exceed the 255 character limit per string. ## Summary Table: SPF Mechanisms Mechanism | DNS Lookup? | Risk | Recommendation `ip4` / `ip6` | No | Low | Use for static IPs `include` | Yes | High | Use sparingly, monitor chains `a` | Yes | Medium | Avoid if possible, use `ip4` `mx` | Yes | Medium | Avoid if possible `ptr` | Yes | High | Do not use (deprecated) By managing your SPF records proactively, you avoid the `permerror` that kills deliverability before your email even reaches the spam filter. Whether you are using a simple API or a complex agentic system, keeping your DNS lean is the best way to ensure your transactional mail is accepted. For a complete set of tools to manage your domain authentication, visit https://sendhq.cc. ## Keep reading - [DMARC p=none vs Quarantine vs Reject: An Operator's Guide](https://sendhq.cc/blog/dmarc-policy-p-none-quarantine-reject): Choosing the right DMARC policy is a balancing act between security and deliverability. Learn the safe rollout path from p=none to p=reject Read article → - [How to Receive Email with Amazon SES: S3 and Lambda](https://sendhq.cc/blog/receive-email-amazon-ses-s3-lambda): Build a production-ready inbound email pipeline with Amazon SES, S3, and Lambda, including MIME safety, tenant routing, idempotency, retries Read article → - [Amazon SES Pricing Tiers Explained (July 2026)](https://sendhq.cc/blog/amazon-ses-pricing-tiers-2026): Amazon SES shifted from a simple a la carte model to tiered plans (Essentials, Pro, Enterprise) on July 21, 2026. Here is the cost breakdown Read article →