SPF "too many DNS lookups" (permerror): the 10-lookup limit and how to fix it

A client's SPF record has grown one include: at a time: Microsoft 365, then the marketing platform, then the help desk, the CRM, the e-signature tool, and an old web host no one remembers. One day a checker reports PermError: too many DNS lookups, and the client's mail starts failing SPF at some receivers. Here's what the limit actually is, how to count lookups correctly, and how to get back under it without creating a maintenance problem.

The rule: 10 DNS-querying terms per evaluation

RFC 7208 §4.6.4 is specific. These terms cause DNS queries during SPF evaluation:

• include
• a
• mx
• ptr
• exists
• the redirect modifier

Implementations MUST limit the total number of those terms to 10 during an SPF evaluation. If the limit is exceeded, the implementation MUST return permerror.

These don't count: all, ip4, ip6, and the exp modifier (which is only looked up later).

Three details trip people up:

1. Nested includes count. The limit covers the whole evaluated tree, not only your top-level record. Microsoft's example: an include: that points to a record with three more includes adds four lookups. Having fewer than 10 include: statements doesn't guarantee fewer than 10 lookups.
2. mx and ptr have sub-limits. Each mx mechanism counts toward the 10, and RFC 7208 also says evaluating the MX records MUST NOT require more than 10 address (A/AAAA) lookups, or mx returns permerror. ptr is limited the same way, and RFC 7208 says ptr "SHOULD NOT be published" at all.
3. Evaluation stops at the first match. Microsoft points out that receivers evaluate left to right and stop when the source matches. So a broken record can still pass for some messages and fail for others, which makes the problem look intermittent.

The other limit: void lookups

RFC 7208 also defines void lookups: DNS queries that return no answer (NOERROR with zero answers) or NXDOMAIN. Implementations SHOULD limit void lookups to two, and going over produces permerror. The usual cause is an include: for a vendor domain that no longer publishes SPF, or an a:/mx: pointing at a hostname that's been deleted. Microsoft also warns that if an include: domain doesn't resolve or has no SPF record, SPF returns permerror. So a dead include is a problem even when you're well under 10.

Other permerror causes worth ruling out

• Two SPF records. If more than one TXT record at the name starts with v=spf1, RFC 7208 §4.5 says the result is permerror. This often happens when a new provider's setup guide says "add this TXT record" and someone adds a second one instead of merging.
• Syntax errors. Microsoft lists common ones: a trailing dot after the domain, include= instead of include:, and a space after the colon.
• Size. RFC 7208 §3.4 recommends keeping the SPF answer small enough to fit in a 512-octet UDP response (it suggests under 450 octets for the name plus records). One TXT string can't exceed 255 characters, but a record can be split into several strings that are joined together without spaces (§3.3).

How to fix it, in order of preference

1. Remove what's no longer used. This is the safest fix and usually the biggest win. For each include, ask the client whether they still use the service and whether it actually sends mail as their domain. Old web hosts, retired marketing tools, and "just in case" includes are common. Google's guidance is the same: keep SPF current by removing domains or IPs you no longer use for sending.

2. Remove redundant mechanisms. An a or mx term that duplicates IPs already covered by an include costs a lookup and adds nothing. If inbound MX hosts don't send outbound mail as the domain, mx may not belong in the record at all. Check with the client before removing anything.

3. Move third-party senders to subdomains. Microsoft recommends this for services you don't control, such as bulk email. Something like marketing.example.com gets its own SPF record and its own 10-lookup budget, and keeps the main domain's reputation separate. DMARC can still align under relaxed mode, because the subdomain shares the organizational domain.

4. Lean on DKIM for vendors that support it. DMARC passes if SPF or DKIM passes in alignment. If a vendor signs with the client's domain, its SPF include may not be needed for DMARC. Check what the vendor uses as the envelope sender first.

5. Flatten, carefully. Flattening replaces an include: with the ip4:/ip6: ranges it resolves to. That removes lookups, but the IPs are now frozen in your record. Microsoft's guidance is useful here:

• It's appropriate for vendors with stable, documented IP ranges.
• Don't flatten Microsoft 365 (include:spf.protection.outlook.com), because Microsoft's sending IPs change frequently. The same applies to any cloud service with changing IPs.
• If you flatten, document what you replaced and when, monitor the vendor's documentation, review at least quarterly, and test after every change.

A flattened record that goes stale fails quietly. The vendor adds a new IP range, and that mail starts failing SPF with nothing in your record to tell you why. If you flatten at scale, Microsoft notes that third-party flattening services exist to automate the tracking. Review any of them carefully before relying on one.

A quick worked count

v=spf1 include:spf.protection.outlook.com include:_spf.google.com mx a include:vendor.example -all

When we checked on Oct 13, 2026, spf.protection.outlook.com and _spf.google.com each contained only ip4/ip6 ranges, so 1 lookup each. mx and a add 1 each. If vendor.example contains three nested includes, it costs 4. The total is 8: under the limit, but with little room left. Provider records change, so re-count before every edit.

Count your lookups now

Run the free SPF checker →

It counts every DNS lookup toward the RFC 7208 limit of 10, walks the include and redirect tree, names the services it recognizes, and suggests cleanup or flattening when you're over. A lookup that times out shows as Unknown, not as missing.

Founding Partner: $1,999, one time. Find over-limit SPF records across every client before their mail fails. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →