SPF Lookup – Complete Guide to SPF Records, Includes and the 10-Lookup Limit

SPF problems rarely announce themselves. Mail keeps flowing until a receiver starts rejecting it, and then the bounce says something vague like "SPF PermError" or "not designated as permitted sender". Typical causes are a second SPF record added by a new provider, an include chain that silently grew past ten DNS lookups, or a forgotten +all that authorizes the whole internet.

The SPF Lookup fetches a domain's SPF record, expands every include: and redirect= recursively, counts the DNS lookups against the RFC 7208 limit and evaluates the final all policy. Use it before and after you add a new email service, when DMARC reports show SPF failures, or when a bounce mentions SPF.

What is SPF?

In simple terms

SPF (Sender Policy Framework) is a published guest list. The domain owner lists in DNS which servers may send mail for the domain. When a message arrives, the receiving server checks whether the sending server's IP address is on that list. If it is not, the receiver can treat the message as suspicious or reject it, depending on what the owner asked for.

Technical background

SPF is specified in RFC 7208. The record is a TXT record at the domain itself, starting with v=spf1, followed by terms evaluated left to right:

• Mechanisms: ip4:, ip6:, a, mx, include:, exists:, ptr and all. The first mechanism that matches the client IP decides the result.
• Qualifiers in front of a mechanism: + pass (the default), - fail, ~ softfail, ? neutral.
• Modifiers: redirect= (use another domain's policy if nothing matched) and exp= (explanation text for failures).

SPF checks the domain in the SMTP MAIL FROM (envelope sender, visible later as Return-Path), and the HELO name. Two limits protect receivers: no more than 10 DNS-querying terms (include, a, mx, ptr, exists, redirect) per evaluation, and no more than two void lookups. Exceeding the first is a PermError. The ptr mechanism is deprecated by RFC 7208 section 5.5.

A typical record:

example.com.  IN TXT "v=spf1 mx ip4:192.0.2.0/24 include:_spf.example.net -all"

The command-line equivalent for the first step is dig TXT example.com +short; expanding the includes and counting lookups by hand is where a tool saves time.

Why use an SPF lookup?

• Find PermError causes: multiple records, too many lookups, broken includes.
• Audit authorized senders before adding or removing an email service.
• Catch dangerous policies such as +all or ?all.
• Understand DMARC reports that show SPF failures for legitimate sources.
• Plan flattening when a domain uses many SaaS senders and approaches the limit.

Who should use it?

• Mail and DNS administrators maintaining a domain's email authentication.
• Marketing operations and IT teams onboarding new sending platforms.
• Security teams reviewing spoofing protection and DMARC readiness.
• MSPs auditing customer domains.

How SPF lookup works

A receiving server evaluates SPF like this: fetch the TXT records of the envelope domain, select the single v=spf1 record, then walk its terms, performing DNS queries for include, a, mx and similar mechanisms until one matches the client IP.

The NetTools.tech SPF Lookup does not test a specific IP. It analyzes the whole policy:

1. The domain is validated (public names only) and its TXT records are queried from the NetTools.tech server through the public resolvers 1.1.1.1 and 8.8.8.8. TXT strings split into several quoted parts are joined, as receivers do.
2. All records starting with v=spf1 are collected. More than one is an error.
3. The first record is parsed into qualifier, mechanism and value. Each include: target and a redirect= target is fetched and expanded recursively, up to 10 levels deep and about 30 expansions in total.
4. Lookup-counting terms are added up across the whole tree: every include, a, mx, ptr, exists and redirect.
5. Include or redirect targets that have no SPF record are counted as void lookups.
6. Targets that contain SPF macros (%{…}) are shown but not expanded.
7. Findings are generated: lookup count, void lookups, the all qualifier, deprecated ptr, errors in included records and very long records.

The operation has a 20-second limit. If the resolver fails or times out for the main record, the tool reports an error rather than "no record".

How to use the NetTools.tech SPF Lookup

1. Open SPF Lookup.
2. Enter the domain in the Domain field, for example example.com. For mail sent with a subdomain in the envelope sender (for example bounce.example.com), check that subdomain.
3. Press Run SPF Lookup.
4. Read the record and lookup count, then the findings, then the include tree and the expandable Mechanisms table.
5. Use Copy for a ticket, or Open in terminal to run /spf example.com in the web terminal.

Understanding the results

Example: a record close to the limit

Illustrative result for a hypothetical domain example.org (all names are examples):

Findings:

• Warning: "8 of 10 DNS lookups used — close to the limit."
• Info: "“~all” (soft fail): unlisted senders are marked suspicious. Use -all once all senders are listed."

Include tree (shown by the tool as a Domain / Record table, indented by depth):

example.org                  v=spf1 mx include:_spf.example.net include:mail.example.com ~all
  _spf.example.net           v=spf1 include:_netblocks1.example.net include:_netblocks2.example.net ~all
    _netblocks1.example.net  v=spf1 ip4:198.51.100.0/24 ~all
    _netblocks2.example.net  v=spf1 ip4:203.0.113.0/24 ~all
  mail.example.com           v=spf1 a mx include:relay.example.com ~all
    relay.example.com        v=spf1 ip4:192.0.2.0/24 -all

Counting: mx (1) + two top-level includes (2) + two nested includes (2) + a, mx and one include in mail.example.com (3) = 8. Adding one more SaaS include with nested includes would push the domain over the limit. Removing the redundant mx at the top level, or replacing mail.example.com with its actual ip4: ranges, frees lookups.

Common use cases

• Adding a new newsletter or ticketing platform without breaking existing senders.
• Diagnosing "SPF PermError" in bounces or DMARC aggregate reports.
• Cleaning up after a provider migration: remove includes of services you no longer use.
• Preparing to move from ~all to -all and from DMARC p=none to enforcement.
• Building a new record with the SPF Record Generator and verifying it here after publishing.

Troubleshooting

Two SPF records after adding a provider

Many providers' setup wizards say "add this TXT record", and the result is a second v=spf1 record. Merge the provider's include: into your existing record and delete the extra one.

Over 10 lookups

Remove unused includes, drop a/mx if those servers do not send mail, replace small includes with their ip4:/ip6: ranges (and monitor them for changes), or move some senders to a subdomain with its own SPF record.

"no SPF record" for an included domain

The include target does not publish SPF. The provider may have renamed it, or there is a typo. Check the provider's current documentation. Each such target also counts as a void lookup.

SPF fails although the record looks right

Check which domain is actually in the envelope sender with the Email Header Analyzer: many platforms use their own bounce domain, so your record is not evaluated at all. Forwarded mail also fails SPF by design.

"DNS lookup … timed out" or SERVFAIL

The domain's name servers did not answer. Query them directly with dig @ns1.example.com TXT example.com and check the delegation.

Common mistakes

• Publishing SPF as the obsolete SPF record type instead of TXT.
• Writing include: for IP addresses, or ip4: for host names.
• Using +all to "make SPF pass", which removes all protection.
• Adding -all before every legitimate sender is listed.
• Forgetting that the 10-lookup limit counts nested includes.
• Putting the record on _spf.example.com or www instead of the domain used in the envelope sender.

Limitations

• The tool analyzes the policy; it does not evaluate SPF for a specific sending IP address.
• SPF macros are shown but not expanded, so lookups behind them are not counted.
• Additional address lookups caused by the mx mechanism (one per MX host) are not counted separately.
• Unknown or malformed terms are reported as errors (prefixed with the domain), both in the domain’s own record and in included records; only the first record found for each domain is parsed.
• Results come from 1.1.1.1 and 8.8.8.8 and may be cached; a just-published change may not be visible yet.
• Recursion stops after 10 levels or about 30 expansions.

Security & privacy

The domain is sent to the NetTools.tech server, which queries public resolvers; the domain's name servers see the server's address, not yours. Only public domain names are accepted, results are not stored, and the tool log keeps the tool name, the domain and your shortened IP address for 30 days (see the privacy policy). No credentials are needed.

Related tools

• SPF Record Generator – build a valid record in your browser (guide).
• DMARC Lookup – check the policy that builds on SPF and DKIM (guide).
• DKIM Lookup – check the signing key, which survives forwarding (guide).
• Email Header Analyzer – see which envelope domain and SPF result a real message got (guide).
• Email Health Check – SPF together with MX, DMARC, DKIM and transport security (guide).

Summary

SPF tells receivers which servers may use your domain in the envelope sender, and it breaks quietly when records are duplicated, include chains grow past ten lookups or the all policy is wrong. The NetTools.tech SPF Lookup expands the full include tree, counts lookups and void lookups, and explains the final policy. Pair it with DKIM and DMARC checks, because SPF alone does not protect the visible From address.