A small business owner forwarded us a screenshot last month. Her invoices were landing in the spam folder, her booking confirmations were bouncing back from a handful of recipients, and her marketing platform support team had told her it was “a DNS issue on her end.” She had a DMARC record at p=quarantine. She had set up DKIM. She had carefully built an SPF record that included every sender she used. So why was her authentication breaking?

The answer was a single line in a DMARC aggregate report: permerror. Her SPF record was syntactically perfect. The problem was that fully evaluating it required 14 DNS lookups, and the SPF specification caps that at 10. Once you cross the line, the record stops authenticating mail entirely. It does not warn you. It does not partially work. It just silently fails.

This is one of the most common ways otherwise-careful organizations end up with broken email authentication. And it gets worse the more your business grows.

What the 10-lookup limit actually is

SPF (Sender Policy Framework) lets a domain owner publish a TXT record listing which servers are allowed to send mail on the domain’s behalf. When a receiving server gets a message, it looks up that record and checks whether the sending IP is on the approved list.

The catch: SPF records rarely list IPs directly. Instead, they reference other domains using mechanisms like include:, a, mx, redirect, exists, and ptr. Each of those references requires the receiving server to perform another DNS lookup to resolve. RFC 7208 (the SPF specification) caps the total number of those lookups at 10 per evaluation, including everything inside nested includes.

The reason the limit exists is denial-of-service prevention. Without a cap, a malicious or misconfigured record could force every receiver on the internet into an unbounded DNS recursion. So the standard draws a hard line: more than 10 lookups, the receiver returns a permerror and treats SPF as failed.

Why “permerror” is worse than “fail”

If SPF returns fail, you at least know the record was evaluated and the sending IP was not on the list. That is a clear, debuggable result.

permerror is different. It means the receiver could not evaluate your record at all. Modern receivers treat permerror as a hard failure for SPF alignment. Your DMARC record then has nothing to align against on the SPF side, and unless DKIM is signing every legitimate message and aligning correctly, DMARC enforcement will start rejecting or quarantining real mail.

The cruel part is that permerror is invisible to you unless you are actively reading DMARC aggregate reports. The mail just stops landing. Your customers stop getting receipts. Your sales team starts hearing “did you send that yesterday?” Your support tickets quietly go to spam folders.

How organizations end up over the limit despite their best intentions

Almost no one publishes an SPF record on day one with 14 lookups in it. They get there by addition, one cloud service at a time:

• Year one: You set up Google Workspace. Your SPF record is v=spf1 include:_spf.google.com -all. That is one include, which itself resolves to a few more. Total lookups: around 4. Comfortable.
• Year two: You add a marketing platform (Mailchimp, HubSpot, Constant Contact, whichever). Their docs tell you to add include:servers.mcsv.net or similar. Now you are at 6 or 7.
• Year three: A help desk product joins the stack (Zendesk, Freshdesk, Intercom). Another include. You are at 9.
• Year four: Sales adds an outbound prospecting tool. Finance adds an invoicing platform. HR adds a recruiting product. Each of them needs to send mail as your domain. Each adds an include:. You are now at 13, and your SPF record returns permerror to every receiver on the internet.

The frustrating part is that nothing in this story was wrong. Each tool is legitimate. Each include is necessary. The IT team followed every vendor’s documentation correctly. SPF as a protocol simply does not scale to a modern cloud-software stack, and the 10-lookup cap was written in 2014 for a world that no longer exists.

Diagnosing a suspected permerror

If you suspect your SPF record is over the limit, here is the order of operations:

1. Pull a fresh DMARC aggregate report. If your domain has DMARC at all (even at p=none), look at the <auth_results><spf> section across recent reports. Repeated permerror results from major receivers like Google and Microsoft are the giveaway.
2. Run an SPF lookup count. Public tools like dmarcian’s SPF Surveyor, the Kitterman SPF testing tool, or any flattening service will count your lookups and show you which include is pushing you over. The result page typically lists each mechanism and its cumulative cost.
3. Check what receivers are seeing. Send a test message to a Gmail address and view the original. Look at the Authentication-Results header. If you see spf=permerror, you have confirmed it from the receiving side, not just from a tool.
4. Check the void lookup count too. RFC 7208 also caps “void” lookups (those returning no records) at 2. This trips people up less often, but it is a related failure mode worth ruling out.

Once you have confirmed the record is over the limit, you have three real fix options.

Fix option 1: Manual flattening

Manual flattening means replacing include: mechanisms with the actual IP addresses they would resolve to. Instead of include:_spf.google.com, you list Google’s published sending IP ranges directly using ip4: and ip6: mechanisms, which do not count against the lookup cap.

This works. It is also painful and fragile.

It is painful because cloud senders use a lot of IPs, and you have to fit them all into a single TXT record (which has its own size limits) or split across multiple included subdomains.

It is fragile because the IPs change. Google rotates ranges. Marketing platforms expand their infrastructure. Every time a sender adjusts their published _spf.example.com record, your flattened version goes stale, and authentication starts failing for whatever messages happen to come from new IPs. There is no automatic notification. You find out the same way the small business owner above did: by reading DMARC reports, or by losing customers.

We have seen organizations do manual flattening successfully. They tend to be the ones with a dedicated person who treats their SPF record like a piece of monitored infrastructure and reviews it monthly. That is most organizations’ aspirational state, not their actual state.

Fix option 2: Remove senders

The other “manual” option is to reduce the number of services that send mail as your primary domain. Move marketing email to a subdomain (mail.example.com) with its own SPF record. Move transactional email to another subdomain. Consolidate vendors where possible.

This is good hygiene and we recommend it where it is feasible. The reality, though, is that for most growing businesses, the senders are there because the business needs them. Telling sales to stop using their prospecting tool because of an SPF lookup is not a real conversation. The technical constraint should not dictate which business tools you use.

Fix option 3: Automated flattening as a service

The third option is to let a service maintain the SPF record on your behalf. The service publishes a flattened record at a domain you control, monitors all the upstream senders for changes, and updates the flattened record automatically whenever an upstream IP changes. Your DNS just contains a single CNAME or include pointing at the managed record.

This is what AutoSPF does. Disclosure: we make it. It is part of DuoCircle’s email authentication portfolio, alongside DMARC Report and Phish Protection. AutoSPF runs for organizations from single-domain SMBs through a $16B IT services firm, and it solves the lookup problem the way the lookup problem actually wants to be solved: by treating SPF as a piece of infrastructure that needs continuous maintenance, not a static text file you set once and forget.

We built AutoSPF specifically because the only major SPF flattening service available at the time was quoting $1,000 a month to a customer who was paying us $4 a month for their email hosting. The math did not work. SPF flattening should not be enterprise-priced infrastructure software, because the people who need it most are the small and mid-market businesses whose SPF records have outgrown the spec.

What to do next

If you suspect you might be over the lookup limit, two things are worth doing this week:

1. Check your record. Run an SPF lookup-count tool against your domain. If you are at 8 or 9, you are one new SaaS tool away from breaking. If you are over 10, you are already broken and probably do not know yet.
2. Get DMARC reporting set up if you do not have it. SPF problems are invisible without aggregate reports. DMARC Report is the natural next step once your SPF foundation is solid, and it will tell you in detail what receivers are seeing when they evaluate your mail. The full authentication portfolio is built around the idea that SPF, DKIM, and DMARC only work when all three are right at the same time, and visibility is what keeps them right over time.

The 10-lookup limit is a real constraint with a real fix. The hard part is knowing you have hit it. Once you do, the path forward is straightforward.