The 10-Lookup Trap: our SPF Generator helps build records that actually work

SPF is one of those technologies that looks deceptively simple when you first encounter it. You read a quick tutorial, throw together a TXT record that lists your mail servers and a few third-party services, and move on with your life.

Everything seems fine for a while.

Then one day, seemingly out of nowhere, your email starts failing authentication. Your DMARC reports show SPF failures across the board. Your marketing campaigns are landing in spam. And when you investigate, you discover that adding that one extra email service last month pushed you over the 10 DNS lookup limit, causing SPF to return a PermError for every single message...

We've been there.

The 10-lookup limit is the single most common cause of SPF failures that we see, and it catches almost everyone off guard because nothing in the basic SPF tutorials warns you about it. You can have a syntactically perfect SPF record that lists every legitimate sending source, and it will still fail catastrophically if it requires more than 10 DNS lookups to evaluate.

The result is not a partial failure or a degraded authentication, it is a complete collapse where SPF stops working entirely.

We built a free SPF record generator specifically to address this problem. Free of charge.

Our tool does not just assemble SPF syntax for you. It counts DNS lookups in real-time as you add sending sources, warns you when you are approaching the limit, and shows you exactly which services are consuming your lookup budget. By the time you finish configuring your record, you know it will actually work in production rather than failing silently when receivers try to evaluate it.

Understanding What SPF Actually Does

Before diving into the generator, it helps to understand what SPF accomplishes and how it fits into the broader email authentication picture. SPF stands for Sender Policy Framework, and at its core it answers a simple question: is this server authorized to send email on behalf of this domain?

When someone sends an email claiming to be from your domain, the receiving mail server can check your SPF record to see if the sending server is on your authorized list. Your SPF record is a TXT record published in DNS that contains a list of IP addresses, IP ranges, and other domains that are allowed to send mail as you. If the sending server matches something in your SPF record, SPF passes.

If it does not match anything, SPF fails.

This mechanism helps prevent email spoofing because attackers cannot easily control which IP addresses send their spoofed messages. If an attacker tries to send phishing email claiming to be from your domain, they would need to send it from an IP address that is listed in your SPF record.

Unless they have compromised one of your legitimate email servers or services, the message will fail SPF and receivers can treat it with appropriate... suspicion.

SPF works in conjunction with DKIM and DMARC to provide comprehensive email authentication. SPF validates the sending server, DKIM validates that the message content has not been modified, and DMARC ties them together with policy enforcement and reporting.

For a complete understanding of how these protocols interact, our documentation on SPF overview, strengths and weaknesses provides the technical foundation.

The 10-Lookup Limit Explained

The SPF specification, defined in RFC 7208, includes a hard limit of 10 DNS lookups during SPF evaluation.

This limit exists to prevent SPF from being abused for denial-of-service attacks. Without a limit, an attacker could craft an SPF record that causes receivers to perform thousands of DNS queries for every incoming email, effectively using email receivers as an amplification vector for DNS attacks.

The limit is sensible from a security perspective, but it creates serious practical problems for organizations that use multiple email services. Here is why:

When you include an external domain in your SPF record using the include: mechanism, the receiver must perform a DNS lookup to retrieve that domain's SPF record. But it does not stop there. If that external SPF record also contains include: statements, those trigger additional lookups. And if those records contain more includes, even more lookups occur. The limit of 10 applies to the total number of lookups across this entire chain, not just the lookups in your own record.

Modern organizations commonly use many third-party services for email: Google Workspace for corporate email, SendGrid for transactional email, Mailchimp for marketing campaigns, Zendesk for customer support, HubSpot for sales outreach, Salesforce for CRM notifications.

Each of these services publishes its own SPF record that you need to include, and each of those includes might trigger multiple additional lookups.

Let us walk through a realistic example. You start with a fresh SPF record:

v=spf1 include:_spf.google.com -all

That single include for Google Workspace does not use just one lookup. Google's _spf.google.com record contains multiple additional includes for their various sending infrastructure. As of this writing, fully resolving Google's SPF record consumes around 4 lookups by itself. You have used nearly half your budget on just one service.

Now add Microsoft 365:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

Microsoft's SPF include chain adds another 2-3 lookups. You are now at 6-7 lookups with just two services configured.

Add SendGrid for transactional email:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

SendGrid adds another 1-2 lookups. You are approaching 8-9 lookups.

Add Mailchimp for marketing (even if it's not necessary due to Return-Path rewriting).

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net -all

Mailchimp adds more lookups, and suddenly you are at 11 or 12. You have exceeded the limit.

When an email receiver tries to evaluate this SPF record, it performs lookups until it hits the limit of 10, then returns a PermError result. The PermError is treated as an SPF failure, which means every email from your domain fails SPF regardless of which authorized server sent it. If your DMARC policy is at p=reject and DKIM is not saving you, your email is now being blocked by your own misconfigured authentication.

The insidious part is that this can happen gradually. Your SPF record works fine for months with 9 lookups. Then someone adds a new email service, pushing you to 11 lookups, and suddenly everything breaks. The connection between adding the new service and email failures might not be obvious, especially if the person who modified the SPF record is not the same person investigating the delivery problems weeks later.

How Our Generator Solves This Problem

Our SPF generator was built specifically to address the lookup limit problem alongside the basic challenge of constructing valid SPF syntax.

Here is how it works and why it is more useful than manual record construction.

When you open the generator, you start by entering your domain name.

The generator then presents you with a list of common email services organized by category: email hosting providers like Google Workspace and Microsoft 365, transactional email services like SendGrid and Mailgun, marketing platforms like Mailchimp and HubSpot, CRM and sales tools like Salesforce and Outreach, helpdesk and support systems like Zendesk and Freshdesk, and others.

For each service, we show the appropriate include statement (if it's appropriate) and, critically, the approximate number of DNS lookups that service consumes.

As you select services, the generator updates the lookup count in real-time. You can see exactly how each addition affects your budget. If you select Google Workspace and the counter jumps from 0 to 4, you know that choice has a significant lookup cost. If you select a smaller service that only adds 1 lookup, you can see that it is relatively cheap in terms of your budget.

When you approach or exceed the 10-lookup limit, the generator displays a prominent warning. It does not silently let you build a record that will fail in production. Instead, it explains the problem, shows you exactly how many lookups you are using, and suggests potential solutions.

Beyond the common services, the generator allows you to add custom entries. You can specify IP addresses directly using the ip4: or ip6: mechanisms, which do not consume any lookups because they do not require DNS resolution.

ou can add additional include statements for services not in our preset list. You can specify the a or mx mechanisms if you need them, though we generally advise against these due to their lookup costs and reliability issues.

The final output is a complete, syntactically correct SPF record that you can copy directly into your DNS. The generator also provides guidance on how to add the record to popular DNS providers and reminds you about common mistakes to avoid.

But that's not finished! You will have to publish and use our DNS SPF analyzer to get the real live data and real DNS queries count. The generator does an approximation because it is running in your browser and lacks the proper access to the DNS system that our servers have.

Strategies for Staying Under the Limit

When you discover that your SPF record exceeds the 10-lookup limit, you have several options for addressing the problem.

Our generator helps you evaluate each of these strategies.

The first and most straightforward approach is to audit your includes and remove services you no longer use. Over time, organizations accumulate SPF includes for email services they no longer actively use. Someone signed up for a marketing platform two years ago, added it to the SPF record, and then cancelled the subscription without removing the include.

These zombie includes consume your lookup budget for no benefit. Review each include in your SPF record and verify that you actually send email through that service. If you do not, remove it. But remember our stance on Shadow-IT before slashing entries!

The second approach is to replace includes with direct IP addresses where possible. The include: mechanism triggers DNS lookups, but the ip4: and ip6: mechanisms do not. If a service sends email from a small, stable set of IP addresses, you can list those IPs directly instead of including the service's SPF record.

This works well for services with static infrastructure, but poorly for services with dynamic or frequently changing IPs. Always check with the service provider before using this approach, as many explicitly advise against it because their IPs can change without notice. Please note that you don't have to use unique IPs, whole subnets are OK.

The third approach is to use subdomains for different sending purposes. Instead of including all your email services in the SPF record for your main domain, you can set up separate subdomains for different use cases. For example, you might configure your marketing platform to send from mail.yourdomain.com instead of yourdomain.com. The subdomain can have its own SPF record with its own 10-lookup budget.

This approach requires coordination with your email services and may affect deliverability if the subdomain does not have established reputation, but it is a legitimate way to work around the limit.

The fourth approach is SPF flattening, which involves resolving all the includes to their underlying IP addresses and listing those IPs directly in your record. This eliminates includes entirely, reducing your lookup count to near zero. However, SPF flattening comes with serious operational risks. The IPs behind those includes change over time, and if you are not updating your flattened record when the underlying services change their infrastructure, you will end up failing SPF for legitimate mail.

Some organizations use automated tools to manage flattened SPF records, re-resolving the includes on a schedule and updating DNS automatically. If you go this route, be very careful about the maintenance burden and consider whether the complexity is worth it. Or vibe-code a cron task?

Our generator helps you understand the tradeoffs of each approach. As you build your record, you can see the impact of different choices on your lookup count. If including a service pushes you over the limit, you can evaluate whether using direct IPs is feasible for that service, or whether moving that sending to a subdomain makes more sense.

The Mechanisms and How They Work

SPF records consist of mechanisms and qualifiers that define who is allowed to send email. Understanding these components helps you make better decisions when configuring your record.

The include: mechanism is the most common and tells receivers to also check the SPF record of another domain. When you see include:_spf.google.com, it means "also consider the Google Workspace SPF record when evaluating this message." The include mechanism consumes at least one DNS lookup, plus any additional lookups required to resolve the included record.

The ip4: and ip6: mechanisms authorize specific IP addresses or ranges. These do not require DNS lookups because the IPs are specified directly in your record. For example, ip4:192.168.1.0/24 authorizes any IP in that subnet to send mail for your domain. These mechanisms are lookup-efficient but operationally risky if the IPs change.

The a mechanism authorizes the IP addresses that your domain's A record points to. This seems convenient, but it consumes a lookup and can be fragile if your website and email infrastructure are separate. We generally recommend avoiding this mechanism unless you have a specific reason to use it.

The mx mechanism authorizes the IP addresses of your domain's MX (mail exchanger) records. This also consumes lookups and can be unpredictable if you have multiple MX entries or if they change frequently. Like the a mechanism, we suggest avoiding this unless necessary.

The redirect: modifier tells receivers to use a completely different domain's SPF record instead of the current one. This is different from include: because it replaces rather than supplements. The redirect is less commonly used but can be helpful for organizations that want to centralize SPF management across multiple domains.

The all mechanism is a catch-all that appears at the end of most SPF records. When prefixed with - (like -all), it means "reject everything that did not match a previous mechanism." When prefixed with ~ (like ~all), it means "soft fail" which is treated as suspicious but not definitively failed. When prefixed with ? (like ?all), it means "neutral" which is rarely useful. We strongly recommend -all for most configurations because it provides the clearest signal to receivers that anything not explicitly authorized should be considered spoofed.

Common SPF Mistakes Beyond the Lookup Limit

While the 10-lookup limit is the most catastrophic SPF mistake, there are other common errors that our generator helps you avoid.

Publishing multiple SPF records for the same domain is a surprisingly common mistake. DNS allows multiple TXT records at the same name, and some administrators mistakenly add new SPF records instead of updating the existing one. When receivers find multiple SPF records (multiple TXT records starting with v=spf1), they return a PermError because the situation is ambiguous. Our generator checks for existing SPF records and warns you if one already exists, reminding you to update rather than add.

Forgetting the all mechanism at the end of your record is another common oversight. Without an explicit all statement, SPF uses a default neutral stance, which defeats the purpose of having an SPF record. Receivers will not know what to do with messages that do not match your authorized sources. Our generator always includes the all mechanism and lets you choose between -all (hard fail) and ~all (soft fail), with clear explanation of what each means.

Using mechanisms that do not work as expected is also common, particularly with ptr:. The ptr mechanism performs reverse DNS lookups and was included in early SPF specifications but is now officially deprecated. It is slow, unreliable, and many receivers ignore it entirely. Our generator does not offer ptr as an option because it should not be used in modern SPF configurations.

Syntax errors can also invalidate your entire SPF record. Missing spaces, typos in mechanism names, incorrectly formatted IP ranges, and other small mistakes can cause the entire record to fail parsing. Our generator produces syntactically correct output, eliminating this category of errors.

SPF's Relationship to DKIM and DMARC

SPF is one component of a complete email authentication strategy. It works alongside DKIM and DMARC to provide comprehensive protection. Understanding how these protocols interact helps you configure each one appropriately.

SPF validates the sending server's IP address against your authorized list. This happens at the SMTP envelope level, checking the server that is actively connecting to deliver the message. The strength of SPF is that it is simple to implement and provides a clear yes/no answer about server authorization. The weakness is that SPF breaks when email is forwarded, because the forwarding server's IP is not in your SPF record.

DKIM validates that the message content has not been modified and was signed by an authorized domain. DKIM survives forwarding because the signature is embedded in the message itself, not dependent on the delivering server. The combination of SPF and DKIM provides redundancy, as a message can pass DMARC if either mechanism passes and aligns. Our documentation on DKIM overview, strengths and weaknesses explains this in detail.

DMARC ties SPF and DKIM together with alignment requirements and policy enforcement. Even if SPF passes, DMARC can fail if the SPF domain does not align with the From header domain. This is where many organizations get confused, as SPF can pass and DMARC can still fail due to alignment issues. For an introduction to how DMARC works and why alignment matters, see our guide on introduction to DMARC.

When you build your SPF record, keep DMARC in mind. The domain used for SPF evaluation is the envelope sender (the MAIL FROM address), not the From header. If these are different, which is common with third-party email services, SPF might pass but not help your DMARC result because it does not align.

Many organizations rely primarily on DKIM for DMARC alignment while using SPF as a secondary check.

After You Publish Your SPF Record

Adding the SPF record to your DNS is the beginning of the process, not the end! But if you're reading this article, you're off to a good start.

Here is what you should do after publishing your record.

First, verify that the record is correctly published and resolving. Use our domain checker to see exactly what SPF record is visible for your domain. The checker also evaluates the record and warns about problems like excessive lookups or syntax issues.

Second, monitor your email authentication results. If you have DMARC configured with a rua address (and you should), your aggregate reports will show SPF pass/fail rates broken down by sending source. A sudden increase in SPF failures after modifying your record indicates something was not configured correctly. Register now and enable our DMARC monitoring service! It will support our work.

Third, test from each of your sending sources. Send test messages through each email service you have included and verify that SPF passes. Many email services have built-in diagnostics that show authentication results, or you can use external tools that analyze message headers.

Fourth, maintain the record over time. When you add new email services, update your SPF record. When you decommission old services, remove their includes. Keep the lookup count under control by auditing periodically. SPF is not set-and-forget; it requires ongoing attention as your email infrastructure evolves.

FAQ

What happens if I exceed the 10 DNS lookup limit?

When SPF evaluation exceeds 10 DNS lookups, the receiver stops evaluation and returns a PermError result. This PermError is treated as an SPF failure for DMARC purposes. If your DMARC policy is at p=quarantine or p=reject and DKIM is not saving you, your email will probably be quarantined or rejected. The failure affects all email from your domain, not just some of it, because every evaluation hits the same limit.

Do IP addresses count against the lookup limit?

No. The ip4: and ip6: mechanisms do not require DNS lookups because the IPs are specified directly in your record. You can include as many IP addresses as will fit in your DNS record without affecting the lookup count (while staying under the 255 char limit). However, managing IPs directly has its own challenges because they can change over time.

Should I use ~all or -all?

We recommend -all (hard fail) for most organizations. This tells receivers that any sender not explicitly authorized should be treated as forging your domain. The soft fail ~all was useful during early SPF adoption but now provides weaker security signals. Some organizations use ~all during initial SPF deployment while they verify their authorized sources, then transition to -all once everything is confirmed.

How often do third-party services change their SPF includes?

It varies by service. Major providers like Google and Microsoft occasionally update their SPF infrastructure, which can change the lookup counts their includes consume. This is one reason to monitor your lookup count periodically rather than assuming it stays constant. Our generator shows current lookup counts based on live DNS resolution.

Can I have different SPF records for subdomains?

Yes. Each subdomain can have its own SPF record with its own authorized sources and its own 10-lookup budget. This is a common strategy for organizations that need to authorize many email services without hitting the limit. The subdomain approach does require careful coordination with email services and attention to deliverability implications.

Try the Generator Now

Our SPF generator is completely free, requires no signup, and shows you DNS lookup counts in real-time as you build your record. Stop guessing about whether your SPF record will hit the limit. Know before you publish.

Build an SPF record that actually works, with full visibility into the lookup budget and clear warnings before you create problems for yourself.