Free SPF Lookup Tool
Query any domain's live SPF TXT record in real time. Instantly verify your SPF record is published, formatted correctly, and visible to receiving mail servers.
How to Use This Tool
Enter the domain
Type the domain you want to check — for example, mailtani.com. The tool queries live DNS, so you'll always see the current published record.
Review the result
The raw SPF TXT record is displayed exactly as DNS returns it. Check that all your sending providers are included and the policy is what you expect.
Fix any issues
If the record is missing or wrong, use the SPF Record Generator to build a corrected record and update your DNS.
Why You Would Look Up an SPF Record Rather Than Just Generate One
Generating an SPF record is a one-time task. Looking one up is an ongoing diagnostic activity. You reach for an SPF lookup tool after making changes and wanting to confirm they propagated correctly, when troubleshooting bounce messages or DMARC failures reported in aggregate reports, when onboarding a new email-sending service and needing to verify your existing record can accommodate it, or when investigating a competitor's or partner's authentication posture.
SPF lookup tools perform real DNS queries against authoritative resolvers and return the raw TXT record value along with a parsed breakdown of each mechanism. This is the same query a receiving mail server performs when evaluating your messages, so the result is ground truth. If a lookup returns no record, receiving servers see no record. If it returns a misconfigured record, that is what receivers are evaluating. There is no cached or assumed state — what the lookup returns is the actual authentication stance of your domain at that moment.
Beyond troubleshooting your own records, SPF lookups are useful when you are setting up a new domain and want to see how similar organisations structure their records. They are also a standard step in email security audits, where the goal is to map the full authentication posture of a domain and identify gaps or misconfigurations before they become deliverability or spoofing incidents.
What to Look for in the Lookup Result
When you run an SPF lookup, the first thing to check is whether a record exists at all. A missing SPF record means every receiving server that evaluates SPF against your domain gets a `none` result — which, depending on DMARC policy, may contribute to DMARC failures. If a record exists, verify it begins with `v=spf1` and ends with an `all` mechanism. Records missing the version prefix or the catch-all policy are syntactically incorrect and will produce PermError results at many receivers.
Next, verify that the `all` qualifier reflects your intended policy. If you published `-all` but the lookup shows `~all`, either your change has not propagated yet or you made an error during the update. Check the IP ranges and `include:` statements against your current list of authorised senders. Over time, teams add new sending services but forget to update SPF, so a lookup is a useful periodic audit. Conversely, old include statements for services you no longer use should be removed — they contribute to the DNS lookup count without adding value.
Pay close attention to the DNS lookup count. Each `include:`, `a:`, and `mx:` mechanism triggers an additional DNS lookup during SPF evaluation, and RFC 7208 limits this to ten. A record that appears valid syntactically can still cause PermError in production if its total lookup count — including recursive lookups within included records — exceeds that limit. This is one of the most common root causes of SPF failures in organisations that use many third-party senders.
DNS Propagation, Timing, and Diagnosing Inconsistency
DNS does not update instantly. When you change a TXT record, the change propagates across the global DNS infrastructure at a rate determined by the TTL value of the record. If your TTL is 3600 seconds, some resolvers will continue serving the old value for up to an hour after your change. If your TTL is 300 seconds, propagation is typically complete within ten minutes.
When diagnosing inconsistencies, compare the result from multiple DNS resolvers — your ISP's resolver, Google's 8.8.8.8, Cloudflare's 1.1.1.1, and if possible the authoritative nameserver for your domain. If the authoritative server returns the new value but public resolvers return the old one, propagation is simply in progress. If the authoritative server still returns the old value, the change was not saved correctly in your DNS provider's interface.
A common source of confusion is when an organisation has multiple TXT records that both appear to be SPF. This is an invalid configuration — RFC 7208 forbids more than one SPF TXT record per domain name. If a lookup returns two records starting with `v=spf1`, the result is a PermError and SPF fails. The fix is to merge them into a single record. A good lookup tool explicitly checks for this condition and flags it as an error.
Using SPF Lookups in a Broader Authentication Workflow
SPF lookups are most valuable when used systematically alongside DKIM and DMARC diagnostics. When you receive a DMARC aggregate report showing SPF failures from a particular IP, the workflow is: identify the IP, look up your SPF record to confirm whether that IP is covered, and if not, determine which sending service owns that IP and add it to your record. This cycle — report analysis, lookup, correction — is the practical reality of maintaining email authentication at scale.
For new domain deployments, a structured checklist works best. Publish SPF with `~all`, run an SPF lookup to confirm the record is correctly formed and accessible, send test messages and verify they pass SPF using header inspection, add DKIM and verify via lookup, add DMARC at `p=none` with reporting, and then monitor reports before advancing policy. The lookup step after each change confirms you are working with live DNS reality, not assumptions.
SPF lookups are also useful when investigating deliverability issues with specific mailbox providers. If mail to Gmail is landing in spam but mail to Outlook is fine, and DMARC reports show SPF failing for Gmail traffic, a lookup will confirm whether the issue is a missing record, a failed include, or a DNS lookup count overrun. Isolating the root cause through lookup data is far faster than trial-and-error record changes.
Key Features
Live DNS Resolution
Queries authoritative and public resolvers in real time to return the current live SPF record value.
Recursive Lookup Counter
Follows all include chains and counts total DNS lookups to detect the common ten-lookup PermError.
Mechanism Breakdown View
Parses and displays each SPF mechanism separately with plain-language explanations of what each authorises.
Duplicate Record Detection
Flags when multiple SPF TXT records exist on the same domain, which causes an automatic PermError.
All-Qualifier Highlighter
Prominently displays the catch-all policy qualifier and explains the enforcement implication.
IP Coverage Checker
Enter a specific IP address to test whether it would pass SPF against the looked-up record.
Frequently Asked Questions
Related Tools
Continue your email deliverability setup with these free tools.
Tools Are Just the Start
Once your domain is set up, mailtani handles sending, warmup, sequences, and rotation.
See How mailtani Compares
Deliverability Built Into Every Send
mailtani monitors your SPF, DKIM, and DMARC status automatically so you'll know the moment something changes — no manual lookups needed.
- Real-time authentication monitoring
- Instant alerts on DNS changes
- Inbox warmup & rotation
- One-time price
14-day free trial · €89 lifetime access after