Key takeaways

  • RFC 7208 limits an SPF check to 10 DNS lookups. The mechanisms include, a, mx, ptr and exists, and the redirect modifier, count; ip4, ip6 and all do not.
  • Going over the limit is a permanent error (permerror), and receivers may treat the message as failing SPF. Under DMARC that can mean quarantine or rejection of real mail.
  • The limit counts lookups caused by nested includes, so one vendor's include can use several of your ten.
  • Flattening replaces includes with IP addresses. It gets you under the limit, but the addresses go stale when a vendor changes them, so it needs automation and monitoring.
  • Fewer senders, subdomains for different mail streams, and DKIM-aligned sending reduce the pressure without flattening.
  • RFC 7208 also limits void lookups (names that return nothing) to two, and a TXT string to 255 characters per string.

What SPF does

Sender Policy Framework (SPF), defined in RFC 7208, lets a domain publish a list of servers allowed to send mail for it. The record is a DNS TXT entry that begins with v=spf1. A receiving server looks at the connecting IP address, fetches your record and checks whether the address is on the list. SPF is one input to DMARC, which we cover in a separate rollout article.

The 10‑lookup limit

Evaluating an SPF record can trigger more DNS queries: each include fetches another record, an a or mx needs address lookups, and so on. To stop abusive or accidental load, RFC 7208 section 4.6.4 says an SPF evaluation must not cause more than 10 such lookups. The terms that count are include, a, mx, ptr, exists and the redirect modifier. The terms ip4, ip6 and all do not count, because they need no DNS.

The count is cumulative through nesting. If you include a vendor, and that vendor's record includes three more things, you have used four. An mx term can cost more than one: the standard also limits the number of names an mx or ptr can resolve to at 10 each, and exceeding that is an error too.

What happens when you exceed it

The result is permerror. The standard says the receiver should not treat it as a pass. In practice, how a message is handled depends on the receiver, but you should assume that SPF will fail. With a DMARC policy of quarantine or reject, and no DKIM signature that aligns to rescue the message, the mail may land in spam or be refused. Because DNS answers vary with the vendors' own changes, a record can drift over the limit without you touching it.

A second limit is easy to miss: no more than two void lookups, queries that return no data or a non-existent name. A typo in an include or a vendor that retires a hostname can trigger it.

How to count yours

  • Start at your domain's TXT record and write out every include, a, mx, exists and redirect.
  • Open each include target and repeat, following nested includes.
  • Count each term once for each time it is evaluated. Stop at ten.
  • Use a checker that follows RFC 7208 rather than counting by eye, and re-run it whenever you add a service.

Ways to get back under the limit

  • Remove senders you no longer use. This is the cheapest fix and the one most often skipped. Old marketing and survey tools are common.
  • Use ip4 and ip6 for servers you control, such as your own mail relay. They cost nothing against the limit.
  • Move a mail stream to a subdomain. A billing or marketing platform can send from its own subdomain with its own SPF record, so each record has its own budget of ten. DMARC alignment then needs the subdomain handled properly.
  • Rely on DKIM for third-party senders. DMARC passes if either SPF or DKIM passes and aligns, so a vendor that signs with your domain does not strictly need to be in your SPF record at all, though some also need a return-path arrangement.
  • Use one provider's fewer includes. Some vendors publish a single compact include.

Flattening: what it is and the trade-offs

Flattening means resolving the includes ahead of time and publishing the resulting IP ranges directly. The record then uses ip4 and ip6 terms, which are not counted. It works, and it is sometimes the only practical option when several large vendors are involved. The costs are real:

  • Staleness. Vendors change their sending addresses without telling you. A flattened record that is not refreshed will block real mail from the new addresses, and you may not notice until a complaint arrives.
  • Record size. A TXT string is limited to 255 characters and a DNS response in UDP is meant to stay small, so a flattened record may need to be split across strings or may exceed practical size. RFC 7208 advises keeping the record short enough to fit in a 512-byte UDP response.
  • Operational risk. If a hand-made flattened record is edited by mistake, there is nothing that tracks the vendor's real list.
  • Trust. Automated flattening services work by rewriting your DNS from a third party's data. That is a dependency, and an attack surface, to evaluate like any other supplier.

If you flatten, automate it, monitor the result, check against the vendor's current published ranges, and keep a record of which vendors are flattened. Prefer flattening only the include that causes the overflow, and leave the rest alone.

A short checklist

  • Count lookups today, with a tool that follows RFC 7208.
  • Delete retired senders.
  • Use subdomains for large or unrelated mail streams.
  • Make sure every major sender also signs with DKIM aligned to your domain.
  • If you flatten, automate the refresh and alert on changes.
  • Add an SPF review to your new-vendor process.

If you want your sending domains audited and cleaned up as part of a DMARC project, ask about our Email Security and Archiving service. This article is general information; test DNS changes before you publish them.

Sources

This article is general information, not legal, contracting or technical advice for your environment. Test DNS and mail changes with your own administrator before you publish or enforce a record. Last reviewed .

Next article

Related reading

Need help with this?

Filter threats out of mail, keep every message in an immutable archive you can search, and keep email working when the mail platform goes down.

Email Security, Archiving & Continuity