Free SPF checker
SPF checker: lookup count, include tree, and flatten advice
Count every DNS lookup toward the RFC 7208 limit of 10, name the services in the include chain, and get a flatten or cleanup suggestion when the record would void.
How to read this
SPF (RFC 7208) is a single TXT record on the apex that lists who may send mail for the domain. Receivers look it up, evaluate the mechanisms left to right, and stop at the first match. The last mechanism should be -all (fail) or, while you are still inventorying senders, ~all (softfail).
The hard limit is ten DNS-causing mechanisms and modifiers in the whole evaluated tree: include, a, mx, ptr, exists, and redirect (RFC 7208 §4.6.4). ip4 and ip6 do not count. Nested include: records add their own lookups. Cross 10 and the result is PermError — many filters treat that as a failed check and will not deliver.
Two v=spf1 records are also PermError. Microsoft 365 and Google Workspace each tell you to “add this include.” If you add a second TXT instead of editing the first, you just broke SPF. Merge every include into one string.
+all and ?all are not “permissive but fine.” +all means pass for the entire internet. It also makes DMARC SPF-alignment succeed for forgeries, which defeats DMARC. We flag them. ptr is obsolete and counts as a lookup; do not add it.
This tool walks the include and redirect tree, counts lookups per node, and names the services those hosts belong to (Microsoft 365, Google Workspace, SendGrid, Salesforce, HubSpot, Mailchimp, Amazon SES, and others we already detect in the product). When you are over 10, we tell you to flatten: replace unused include: chains with the ip4/ip6 networks you actually send from, or drop a vendor.
Lookups that time out are Unknown. We will not tell you the record is missing because Cloudflare or Google DoH was slow.
When we print a corrected record, we keep every include: we already saw and only change the dangerous tail (+all, ?all, or a missing all) to -all. We do not invent SendGrid or Salesforce includes you do not have. If Microsoft 365 or Google Workspace is visible from MX and there is no SPF at all, we suggest the include those vendors document. Flattening advice is only shown when the tree is over ten lookups — under the limit, extra flattening is how people freeze stale IP lists and break mail six months later. ptr is counted and discouraged; the exp modifier is not part of the ten. A timeout walking one include is Unknown for that node, not a missing apex SPF record (RFC 7208).
FAQ
- Why do we have to stay under 10 lookups?
- The SPF specification caps recursive DNS to stop cheap amplification. Receivers are required to treat more than ten as a permanent error, not as a soft warning.
- Should we end with -all or ~all?
- -all once every real sender is listed. ~all while you still expect surprises. Never +all.
- Can we have one SPF for Microsoft and one for Google?
- No. One TXT. Put both include: terms in that one record.
- Does flattening stay accurate?
- Vendor IP ranges change. If you flatten, calendar a review or use a flattening service that refreshes. Prefer deleting unused includes first.
Fix this for your clients, white-labeled
Client Posture runs the same checks under your logo, with a branded PDF and a quote attached. MSPs use it to walk into the next meeting with evidence instead of a generic screenshot.