SPF PermError from too many DNS lookups: what the 10-lookup limit means

#email #devops #dns #webdev

SPF has a hard limit of 10 DNS-querying mechanisms per record. Hit that limit and you get a PermError, the same hard failure as having two SPF records. Your record can look perfectly normal from the outside while silently failing for anyone who queries it.

What counts as a lookup

Not every mechanism in an SPF record triggers a DNS lookup.

These count toward the limit:

include:
a
mx
ptr
exists
redirect=

These do not count:

ip4:
ip6:
all

The catch is that include: mechanisms are recursive. If your record has include:sendgrid.net and SendGrid's SPF record itself contains three more include: entries, those all count toward your limit. You can hit 10 with just four or five top-level includes on a typical SaaS stack.

How to count your current lookups

dig TXT yourdomain.com | grep spf

Then trace each include: manually, or run a check at InboxGreen which counts the full resolved lookup depth automatically.

The fix: replace includes with IP addresses

ip4: and ip6: mechanisms do not count as lookups. The goal is to replace include: entries with the actual IP ranges they resolve to.

Before:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:servers.mcsv.net ~all

After:

v=spf1 include:_spf.google.com ip4:198.37.144.0/20 ip4:198.21.0.0/21 ip4:209.61.151.0/24 ~all

Keep include: only for services like Google Workspace that rotate IPs and maintain their own SPF record. Flatten everything else to direct IP ranges.

One downside of flattening: provider IP ranges change over time. Check once a quarter and update, or use a service like AutoSPF that handles updates automatically.