SPF troubleshooting

SPF lookup limit: count nested terms and fix warnings

Reviewed 22 September 2026

A long SPF record needs inspection. Start with the record at the domain your sending service uses for the envelope sender, then review its nested dependencies.

What the limit counts

During evaluation, SPF allows at most 10 DNS-triggering terms: include, a, mx, ptr, exists and redirect. Nested terms count too. Exceeding that limit returns permerror. ip4, ip6 and all do not consume this budget. exp is outside the evaluation budget. Separate limits also apply to MX address lookups and empty DNS answers. RFC 7208, section 4.6.4.

A warning needs context

SPF evaluates mechanisms in order and stops on a match. A message’s sending IP can therefore change how far evaluation proceeds. Moving existing includes into another include does not remove their lookup cost. SPF evaluation rules.

Inboxproof performs a bounded static expansion. Its warning identifies a policy to investigate; it does not reproduce a receiving server’s decision for a particular message. Sender-dependent macros and DNS failures can also limit this check.

Review the services that still send mail

1. List the systems sending mail for this domain, including billing, support, forms and newsletters.
2. Match each provider to its current SPF instructions. Record who owns each service before removing anything.
3. Remove an obsolete include only after confirming the service no longer sends mail.
4. Ask providers about a supported configuration with fewer dependencies. Copying today’s IP addresses creates a maintenance obligation if their infrastructure changes.
5. Recheck DNS after the cache TTL, then send a test through each service. Inspect the receiver’s authentication results.

Microsoft’s setup guide explains how to maintain one SPF record and account for multiple sending sources. Use your actual provider’s values. Microsoft SPF configuration guidance.

Related: Gmail authentication errors · Inspect message headers · Daily domain monitoring