## TL;DR
SPF allows at most 10 mechanisms and modifiers that cause DNS lookups. Every include, a, mx, ptr and redirect costs one, and nested includes cost theirs too. Permerror means receivers must treat the record as broken, which is worse than no record. Count the expanded lookup total with a validator, then cut the biggest nested includes or replace them with ip4 and ip6 ranges you control.

```text
spf "permerror" on dns lookup limit exceeded
```

## Use this when
- An SPF checker reports permerror or a lookup count above 10.
- Mail from a previously working domain started failing after another vendor include was added.

## Not for this skill when
- SPF returns temperror during a DNS outage. That is transient and different from permerror.
- The record has a plain syntax typo and never evaluated. Fix syntax first.

## Steps
1. Run the domain through an SPF validator that expands includes and shows the running lookup count. Verify: the total and the most expensive include are named.
2. List every sender that actually sends for the domain and drop includes for retired vendors. Verify: each remaining include maps to a live sender.
3. Replace a and mx mechanisms with explicit ip4 and ip6 entries where the sending addresses are stable. Verify: the lookup count drops without losing a real sender.
4. If a vendor include alone costs many lookups, ask the vendor for a flatter record or a dedicated subdomain, and consider moving bulk senders to their own subdomain with its own SPF. Verify: no single stream can push the root record over the limit again.
5. Publish the trimmed record, wait for DNS propagation, and re-run the validator plus a real test send. Verify: the validator reports 10 or fewer lookups and receivers show spf=pass.

## Variant phrasings
### spf 10 dns lookup limit permerror fix
The count-first variant searchers use after a validator warning.
### too many spf includes nested lookup count
The nested include variant.

Compatibility: RFC 7208 section 4.6.4 lookup limit, all major receivers enforce it.

## Why it happens
The limit exists to stop SPF evaluation from becoming a DNS amplification tool. Because includes expand recursively, a record that looks short can cost far more than 10 lookups once vendor records add their own includes.

## Edge cases / pitfalls
- Flattening copies vendor IPs into your record and goes stale when the vendor changes ranges. Prefer cutting senders over blind flattening, and re-check flattened records monthly.
- The ptr mechanism is slow, deprecated and still costs a lookup. Remove it.
- Two SPF TXT records on one name also cause permerror. Merge them into one record.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_orfdUd-xXcNwtB7xgsIN4g