SPF exceeding the ten-lookup limit

`include:`, `a`, `mx`, `ptr` and `exists` each cost one lookup, and the mechanisms inside an included record count too, recursively.

`ip4:` and `ip6:` cost nothing. They state addresses directly, which is why they are the way out of the limit.

`redirect=` also costs a lookup and its target's mechanisms count.

So a record with five `include:` entries is not five lookups. A single provider include frequently expands into three or four, and four providers can exceed ten while the record looks short.

The count is per evaluation, not per record. Nothing in your own DNS tells you when you have crossed the line.

Nothing in your systems reports it. The record is syntactically valid, your DNS answers correctly, and the failure happens at the receiving server.

Mail may still be delivered, because receivers weigh many signals and SPF is one. So the symptom is not bounced mail; it is authentication quietly not happening.

That matters because DMARC depends on it. A domain at `p=reject` whose SPF returns `permerror` is relying on DKIM alone, and any path where DKIM is broken — forwarding, some mailing lists — now fails entirely.

The other way it appears is suddenly. A provider adds an include to their own record, your total crosses ten, and a configuration nobody touched starts failing.

`dig example.com TXT +short` returns the record. Read the mechanisms and expand each `include:` by querying that domain's TXT record in turn.

Do it recursively. A provider's include that itself includes two more is three lookups from one entry.

The authoritative confirmation is in a received message: the `Authentication-Results` header written by the receiving server reports `spf=permerror` when the limit was exceeded.

Send a message to an account you control elsewhere, open the original, and read that header. It is the only place the failure is stated plainly.

Remove senders that no longer send. Records accumulate: a marketing platform cancelled two years ago is frequently still listed, consuming lookups for nothing. This is the first thing to check and it often resolves the problem alone.

Flatten an include into the `ip4:` and `ip6:` ranges it resolves to. That costs no lookups and it breaks the day the provider changes addresses, so it needs re-checking rather than setting once.

Move a high-volume sender to a subdomain with its own SPF record and its own ten lookups. Mail from `news.example.com` is authenticated against that subdomain's record, and the apex record stays short. This is the structural answer at scale.

And remove `ptr` if it is present. It is deprecated, slow, treated as unreliable by receivers, and removing it is free.

Two SPF records on one domain is a permanent error as well, and it happens whenever a second service is added by pasting a second record rather than merging into the first.

The specification requires exactly one TXT record beginning `v=spf1`. Two is invalid and evaluation stops.

Merging is mechanical: combine the mechanisms into one record, keep a single terminating `all`, and choose the stricter of the two policies.

Confirm afterwards that exactly one line of the TXT output begins `v=spf1`. Some DNS panels create a second record rather than replacing the first.

`email.spf.lookups` counts the DNS lookups an evaluation of the record would require, expanding includes recursively, and reports the total against the limit.

`email.spf.single` reports the presence of more than one SPF record, and `email.spf.present` and `email.spf.syntax` cover absence and malformed records.

`email.spf.all` reports the terminating mechanism, and `email.spf.ptr` reports the deprecated mechanism if it is present.

The count is of what the record requires at the moment it is read. Provider records change, so a record at nine lookups today is worth re-checking rather than considering settled.