Runbooks
Fix an SPF record that has too many lookups
How do I fix SPF permerror or too many DNS lookups?
SPF allows ten DNS-querying mechanisms and evaluation fails entirely past that, taking every authorised sender with it. Count the lookups including the ones inside each include, remove vendors that no longer send, replace includes with ip4 entries where the vendor publishes stable addresses, and re-check. Do not flatten automatically without a plan to re-flatten.
This is the fault that arrives without anybody changing anything. You added a vendor last month and stayed inside the limit; the vendor added an include to their own record last week and pushed you over it. Nothing warns you, and the sender that breaks is not the one you added.
# What counts towards the limit
| Mechanism | Costs a lookup? | Notes |
|---|---|---|
| include: | Yes | And everything inside it counts too, recursively. |
| a, a: | Yes | One per mechanism. |
| mx, mx: | Yes | One for the MX query, plus one per host returned. |
| ptr | Yes | Deprecated. Remove it. |
| exists: | Yes | |
| redirect= | Yes | And the record it points at is evaluated in full. |
| ip4:, ip6: | No | Free. This is what flattening exploits. |
| all | No |
# Working through it
- Count what you actually have DNSMentor reports the resolved count, including the lookups nested inside each include. That number is usually a surprise — a single Microsoft 365 include can account for three on its own.
- Remove what no longer sends The cheapest lookups to reclaim are the vendors the client stopped using. Ask before removing: an include for a system that sends one invoice a quarter still matters in that quarter.
- Replace stable vendors with ip4 entries Where a vendor publishes a fixed, documented set of sending addresses, an ip4 entry costs no lookup. Only do this where the vendor commits to the addresses in writing.
- Consider a subdomain for bulk sending Marketing platforms and transactional senders belong on their own subdomain with their own SPF record. It removes the lookups from the main domain permanently and limits the reputational damage if the platform is abused.
- Re-check and apply The spf-lookup-limit rule re-counts on the resulting record, so you will know before applying whether you are back under.
Expanding every include into ip4 entries fixes the count today and silently breaks when a vendor changes its addresses. If you flatten, you need something watching for those changes. Prefer removing senders and moving bulk mail to a subdomain.
# Confirming it worked
dig +short TXT contoso.co.uk | grep spf1A record under the limit is not the same as a correct one. Confirm every system the client actually sends from is still authorised — the finance system and the scanner in the corner are the two that get forgotten.
Thanks — noted.
Related
Raise a ticket from inside the platform and your tenant, plan and recent activity come attached automatically. A client currently offline is treated as urgent on every plan.