Skip to content
Clinic open · free diagnosis, no appointment needed2,000+ domains monitored

Over the ten lookup limit? Get a record that fits.

Expands your whole include chain into the addresses behind it and merges them into the fewest blocks that authorise exactly the same senders. Nothing is widened, and nothing you cannot resolve is quietly dropped.

Judged against RFC 7208 section 4.6.4 for the lookup limit and section 5.6 for address mechanisms

Expands every include, a and mx into the addresses behind them. Reads live DNS.

Symptoms

Mail from one particular service stops authenticating, or DMARC reports show SPF failing for senders you know are yours. Nothing changed in your DNS. What changed is that somebody added one more vendor, and the record crossed a limit that has no warning attached to it.

The failure is all or nothing. Past ten lookups the receiver stops evaluating and returns PermError, so SPF fails for every message from the domain, not just the sender that tipped it over.

Diagnosis

SPF is evaluated by the receiver, at delivery time, by following your record. Everyinclude, a, mx, ptr and existscosts one DNS lookup, and the ones inside your includes count against the same budget. Ten is the ceiling for the whole evaluation.

A single include:_spf.google.com is three lookups on its own, because it includes two more records inside it. Add a marketing platform, a helpdesk and a billing service and you are at the limit without having written ten of anything.

Cure

  1. Remove what you do not use. Most records over the limit carry vendors that were replaced years ago. This is the only fix that stays fixed.
  2. Use subdomains for bulk senders. Marketing mail fromnews.yourdomain.com gets its own record and its own ten lookups.
  3. Then flatten what is left. Take the record above, publish it, and put a reminder in your calendar to regenerate it.
  4. Check DKIM is signing. A flattened record that goes stale is survivable if your mail is also DKIM signed, because DMARC passes on either one.

What this tool will not do

It will not widen a range to make the record shorter. Two addresses that are not neighbours stay two entries rather than becoming one block that also authorises somebody else's server.

It will not hand you a record built from a chain it could not fully resolve. If an include fails to answer, you get the failure instead of a record that silently drops a sender you believe is authorised.

Questions people actually ask

What is the ten lookup limit?

RFC 7208 section 4.6.4 caps an SPF evaluation at ten DNS-lookup-consuming terms. include, a, mx, ptr and exists each cost one, and the includes inside your includes count too. Cross the limit and the receiver returns PermError, which most treat as an SPF failure for every message you send.

Does flattening break anything?

It removes the lookups by replacing them with the addresses they resolved to right now. That is the whole risk. Your providers change IPs without telling you, and a flattened record does not follow them. The mail that used to pass starts failing SPF with nothing in your DNS having changed.

How often should I regenerate it?

Whenever you add or remove a sender, and on a schedule otherwise. Monthly is sensible, quarterly is the minimum. Large providers publish their ranges precisely so you do not have to hard-code them, so you are taking on the maintenance they were doing for you.

Is there a better fix than flattening?

Usually. Most records over the limit are carrying vendors nobody uses any more. Removing three dead includes is free, permanent and does not go stale. Look at the chain first and flatten only what is left.

Why did some terms stay in the record?

exists: and ptr are evaluated against the connecting IP for every individual message, so there is no fixed set of addresses to substitute. Anything containing a macro expands differently per message for the same reason. Those are left exactly as they were, and they still cost their lookup.

My record is longer than 255 characters. Is that a problem?

No, as long as it is published correctly. A TXT record is made of character-strings of at most 255 characters each, and a receiver joins them with nothing in between. We split it for you on term boundaries. Most DNS panels handle this automatically when you paste the whole record.

Related tests

Every fix on this site is yours to implement. If you would rather someone did it, I take this work directly.