Counts every DNS lookup in the record

Free tool

SPF checker

Check any domain's SPF record and how close it is to the lookup limit

Free SPF record check for any domain. We resolve the whole record from your browser, follow every include and redirect the way a receiving mail server does, and show you the DNS lookup count out of 10, the void lookups, the default policy, and every IP range the record authorizes.

Enter any domain. You do not need an account, or access to its DNS.

The check runs in your browser via DNS-over-HTTPS, so the SPF record reaches you without passing through our servers. We do receive the name of each domain checked. That name triggers an independent check from our own servers, and we store its result, including the SPF record itself, to keep our public domain index current.

How to use this SPF checker

Three steps, from a domain name to the full lookup count and the policy the record applies.

  1. 1

    Enter a domain

    Type any domain into the form above. You do not need to own it or have access to its DNS.

  2. 2

    We resolve the whole record

    Your browser queries the domain's TXT records over DNS-over-HTTPS, then follows every include, redirect, a, mx, and exists term it finds, exactly as a receiving mail server would.

  3. 3

    Read the count and the verdict

    You get the DNS lookup total out of 10, the void lookup total out of 2, the default policy from the all mechanism, every syntax error, and each authorized IP range grouped by the include it came from.

What an SPF check tells you

An SPF record can be syntactically fine and still fail in production. Use this check to:

  • Confirm a new sender was added correctly after connecting Google Workspace, Microsoft 365, SendGrid, or Mailchimp.
  • See how much headroom is left before the 10-lookup limit, before you add another include.
  • Diagnose a permerror that is failing DMARC even though the mail is legitimate.
  • Find a void lookup left behind by a decommissioned host or a cancelled vendor.
  • Check whether the record ends in -all, ~all, ?all, or nothing at all.
  • Audit a supplier's or an acquired domain's SPF before letting it send on your behalf.

Understanding SPF

The 10 DNS lookup limit

RFC 7208 section 4.6.4 requires receivers to stop after 10 terms that cause a DNS query during a single SPF evaluation. Those terms are the include, a, mx, ptr, and exists mechanisms and the redirect modifier. The ip4, ip6, and all mechanisms cost nothing, and the exp modifier is exempt because its lookup happens after evaluation has finished. Cross the limit and the result is permerror, which receivers treat as an SPF failure for every message the domain sends. The count is recursive: each include adds the lookups of the record it points at, so four includes can easily cost fifteen.

Void lookups, and why the ceiling is two

A void lookup is a DNS query made while evaluating SPF that returns nothing: either NXDOMAIN, or NOERROR with an empty answer section. RFC 7208 section 4.6.4 says implementations should limit void lookups to two and recommends two as the default; beyond that the result is permerror. Void lookups are worth fixing even when the total lookup count is comfortable, because each one means the record still names a host or an include that has been decommissioned.

-all, ~all, ?all, and +all

The all mechanism sits at the end of a record and matches every sender that nothing earlier matched (RFC 7208 section 5.1). Its qualifier decides the verdict. -all is fail: an explicit statement that the sender is not authorized. ~all is softfail: the domain says the sender is probably not authorized but stops short of asserting it, and receivers are told not to reject on that alone. ?all is neutral, which section 8.2 requires receivers to treat exactly like having no record at all. +all authorizes every host on the internet and cancels out the point of publishing SPF. A record with no all mechanism and no redirect also ends in neutral. Aim for -all once your DMARC reports show every legitimate sender is covered.

SPF macros

Macros (RFC 7208 section 7) let a record build the DNS name it queries out of the message being checked, written as a percent sign and a letter in braces. The i macro expands to the sending IP address, s to the full MAIL FROM address, l to its local part, o and d to domain names, and h to the HELO name. Large platforms pair them with exists so one record can answer per customer or per IP without publishing thousands of records. Macros are legitimate and this tool resolves what it can, but a macro means the real answer depends on the message, so no static check can predict it in full. The p macro is the one to avoid: it forces a reverse DNS lookup, the same reason RFC 7208 section 5.5 discourages the ptr mechanism.

SPF flattening

Flattening replaces include, a, and mx terms with the ip4 and ip6 ranges they currently resolve to. Fully inlined by hand, the resulting record costs zero DNS lookups; a managed service publishes it behind a single hosted include, so it costs one. Either way it is the only dependable way to bring a record with many senders back under the limit of 10. The trade-off is that it freezes a snapshot: when a provider changes the ranges behind their include, a hand-flattened record keeps authorizing the old ones and starts failing mail you actually sent. Flattening is therefore only safe when something re-resolves it on a schedule. Flattened records are also long, and a TXT record over 255 characters has to be published as several strings that receivers join back together (RFC 7208 section 3.3).

Frequently asked questions

What is an SPF record?
SPF (Sender Policy Framework, RFC 7208) is a TXT record published in a domain's DNS that lists which servers may send mail using that domain in the SMTP MAIL FROM address. A receiving server reads the record, compares it against the connecting IP address, and returns pass, fail, softfail, neutral, none, temperror, or permerror. DMARC then uses that result, provided the MAIL FROM domain aligns with the domain in the visible From header.
What is the SPF 10 DNS lookup limit?
RFC 7208 section 4.6.4 requires receivers to stop after 10 terms that trigger a DNS query while evaluating one SPF record. The include, a, mx, ptr, and exists mechanisms and the redirect modifier all count; ip4, ip6, and all cost nothing. The limit is recursive, so every include also brings in the lookups of the record it points at. That is why a record with only four or five includes routinely lands over the limit.
What happens when an SPF record exceeds 10 lookups?
The receiver stops evaluating and returns permerror, which is treated as an SPF failure for every message, including mail from your own servers. If those messages are not also signed with an aligned DKIM signature, DMARC fails too and the mail can be quarantined or rejected. The failure is silent from the sender's side: nothing in your DNS changes, so the record can cross the limit the day a provider adds a range to their own include.
What is a void lookup in SPF?
A void lookup is a DNS query made during SPF evaluation that comes back empty: either NXDOMAIN, or a NOERROR response with no answer records. RFC 7208 section 4.6.4 says implementations should limit void lookups to two and recommends two as the default; past that the result is permerror. In practice a void lookup means the record still names a host or an include that no longer exists.
Should my SPF record end in -all or ~all?
-all (fail) is the end state. It tells receivers the sender is not authorized, and it is what makes SPF actually restrict anything. ~all (softfail) is a staging qualifier: the domain says the sender is probably not authorized but asks receivers not to reject on that basis alone. Start on ~all while you confirm from DMARC reports that every legitimate sender is covered, then move to -all. ?all is neutral and, per RFC 7208 section 8.2, must be treated exactly as if no record existed.
What is SPF flattening, and is it safe?
Flattening replaces include, a, and mx terms with the ip4 and ip6 ranges they currently resolve to. Fully inlined by hand, the result costs zero DNS lookups; a managed service publishes it behind a single hosted include, so it costs one. It is the only reliable way to bring a record with many senders back under the limit of 10. Done once by hand it is unsafe, because the record freezes a snapshot and keeps authorizing old ranges after a provider changes theirs. It is safe only when something re-resolves and republishes it on a schedule.
Is this SPF checker free?
Yes, and no signup is required. The lookup runs in your browser against public DNS-over-HTTPS resolvers, so the SPF record reaches you without passing through our servers. We do receive the name of each domain checked. That name triggers an independent check from our own servers, and we store its result, including the SPF record itself, to keep our public domain index current. An SPF record is public DNS data that anyone can query.