SPF "too many DNS lookups": why it happens and how to fix it

SPF tells receiving mail servers which services may send email for your domain. The standard (RFC 7208, section 4.6.4) caps the number of DNS lookups a receiver will do while checking it at 10. Go over the limit and the result is a permanent error (PermError). Most receivers treat that as an SPF failure, and if you also publish DMARC, your legitimate email can be quarantined or rejected.

What counts as a lookup

These terms each cost one lookup, and so do the terms inside every record they pull in:

• include:
• a and mx
• ptr (deprecated, avoid it)
• exists:
• the redirect= modifier

ip4:, ip6: and all are free.

Why it creeps up

Every tool you add tells you to add its include: Google Workspace or Microsoft 365, a CRM, a marketing platform, a helpdesk, an invoicing tool. Each include can contain more includes. include:_spf.google.com alone costs several lookups, because it includes Google's netblock records.

The record looks short, and nobody notices until the eleventh lookup.

How to fix it

1. Remove senders you no longer use. Old marketing tools are the usual suspects.
2. Move bulk senders to a subdomain. Send newsletters from news.example.com with its own SPF record, so they don't count against your main domain.
3. Drop a, mx and ptr unless you really send mail from those hosts.
4. Flatten carefully. Replacing includes with ip4: ranges removes lookups, but the provider's addresses change over time, so a hand-flattened record silently goes stale. Only flatten if something keeps it updated.
5. Keep one record. Two v=spf1 records on the same name is its own permanent error. See DMARC permerror for the other causes.

Unsure whether to end the record with ~all or -all? See SPF ~all vs -all. Once SPF is under the limit, the next step is DMARC: see DMARC p=none to p=reject.

Check your domain

The free scan counts every lookup in your SPF record, including nested includes, and warns you at 9 of 10, before the next tool you add breaks it.