The short answer

SPF has a hard limit of 10 DNS lookups. If checking your record needs more, receivers return an error called a permerror, and SPF fails for every message.

The fix is to cut lookups: remove services you no longer use, swap broad entries for specific ones, and move bulk mail to a subdomain. Flattening the record is a last resort.

Why the limit exists

SPF is defined in a standard called RFC 7208. To stop SPF checks overloading DNS, it caps the number of lookups a receiver will make while checking one message.

These parts of an SPF record each need a lookup and count towards the 10:

  • include:, which pulls in another provider’s SPF record
  • a and mx, which look up your domain’s server addresses
  • ptr, which is outdated and should not be used
  • exists: and redirect=

ip4:, ip6: and all do not count, because they need no lookup.

Nested includes count too. If one provider’s include contains three more includes, that single entry can use four lookups. This is why a short-looking record can still be over the limit.

There is a second limit: no more than two “void” lookups. A void lookup is one that finds nothing, often an include for a service that has closed or changed its address.

Why it matters for DMARC

DMARC needs either SPF or DKIM to pass and match the domain in the “from” address. A permerror means SPF fails for every message, so you are relying on DKIM alone.

If any of your services is not signing with DKIM for your domain, its mail now fails DMARC. With a quarantine or reject policy, that mail goes to junk or bounces. See what DMARC is and how to set it up for the full picture.

An example of a record over the limit

Here is a record many businesses end up with after a few years:

v=spf1 a mx include:spf.protection.outlook.com include:_spf.google.com include:newsletter.example include:crm.example include:helpdesk.example ~all

It looks like seven entries. But the Google include contains several includes of its own, and each tool may add more. Counted fully, a record like this can easily pass 10.

In this example, the business uses Microsoft 365 for mail, so the Google include is left over from an old setup. Removing it, plus a and mx, may be enough to bring it under the limit.

Two quick checks first

  • Only one SPF record. A domain must have exactly one TXT record starting v=spf1. Two records cause a permerror on their own, whatever the lookup count.
  • Count your lookups. Our free email check shows your SPF record. An SPF checking tool can count the lookups, including nested ones.

How to fix it, safest first

  1. Remove services you no longer use. Old website hosts, past newsletter tools and trial services often stay in the record for years. Confirm with your team before removing each one.
  2. Replace a and mx where possible. If your mail is sent by Microsoft 365 or Google Workspace, their include already covers them. Entries for your own servers are often unnecessary.
  3. Use specific IP addresses for fixed servers. If a server of your own sends mail from a fixed address, an ip4: entry costs no lookup.
  4. Move marketing mail to a subdomain. Send newsletters from something like news.yourdomain.co.uk, with its own SPF record. Each subdomain gets its own 10 lookups.
  5. Rely on DKIM where the tool supports it. Some services align through DKIM, so they may not need to be in your SPF record at all. Check each provider’s guidance first.
  6. Flatten only as a last resort. Flattening swaps includes for the IP addresses behind them. It works, but providers change their addresses without warning. Only flatten with a tool or service that monitors and updates the record.

~all or -all?

The end of your SPF record says what to do with mail from unlisted senders. ~all is a soft fail: treat it as suspicious. -all is a hard fail: it is not authorised.

Once DMARC is in place, receivers mostly follow your DMARC policy instead. Many businesses use ~all, which avoids rejecting forwarded mail too early. Neither option fixes a lookup problem.

A safe order of work

  1. List every service that sends email as your domain.
  2. Check which of them also sign with DKIM for your domain.
  3. Draft the new SPF record and count its lookups before publishing.
  4. Change the record during a quiet time, keeping a copy of the old one.
  5. Send test messages from each service and check the headers show SPF pass.
  6. Watch your DMARC reports for a week for any sender that starts failing.

If you are not comfortable editing DNS, get help. See fixing emails that go to spam, DMARC setup and why business emails go to spam.