Test an IP against SPF
Use the domain from Return-Path, not the From: header — SPF checks the envelope sender. Get the IP from the first Received: line the receiver added, or from the header analyzer.
How it works
Fetch
The domain's SPF record is fetched over DNS-over-HTTPS. Two records or none is reported before any IP is tested.
Walk
Each mechanism is evaluated left to right for the IP: ip4 and ip6 by CIDR, a and mx by resolving them, ptr by reverse then forward lookup, include and redirect recursively.
Match
The first mechanism that matches decides the verdict via its qualifier — pass, fail, softfail or neutral. The path shows which include it came through.
Count
Every include, a, mx, ptr, exists and redirect is a DNS lookup. Over ten and receivers return permerror regardless of what would have matched.
The question the SPF checker cannot answer
A record validator tells you the syntax is fine and the includes resolve. It cannot tell you whether the server that actually sent last Tuesday's message is inside any of them. That is what this does: give it the envelope-from domain and the IP from the receiver's Received: header, and it walks the record the way Gmail or Microsoft's SPF evaluator walks it, mechanism by mechanism, and shows which one matched. When the answer is softfail on a domain you were sure was set up, the "via" column shows exactly which include the IP is missing from.
Why the mechanism matters, not just the verdict
Two passes are not equal. A pass on ip4:203.0.113.0/24 in your own record is a pass you control. A pass on include:_spf.salesforce.com is one that vanishes the day someone tidies the record. And a pass on +all is not authentication at all; filters weight it as if the record did not exist. The table shows the term that fired so you know which kind you have. It also shows the path, because a fleet of forty domains all including a shared subdomain has one point of failure, and this is where you find it.
Envelope-from, not From:
The most common reason the tool says fail when the message clearly delivered is testing the wrong domain. SPF is evaluated against the Return-Path — the bounce address — which for most sending tools is a subdomain or the tool's own domain, not the address the prospect sees. Copy the domain from Return-Path in the headers. If the From: domain and the Return-Path domain differ and you want DMARC to pass on SPF, they need to share an organisational domain; the alignment checker works that part out.
What the lookup count is telling you
The count is not the total for the record; it is how many DNS-querying terms were spent before the match. That is the number a receiver actually pays, and it explains a puzzle: an IP that matches early in a bloated record passes fine, while an IP that would match in the eighth include never gets there because the evaluator hit ten and gave up. If the count is near the limit for a passing IP, the record is one added include away from breaking. The flattener is the fix.
Frequently asked questions
Which domain do I test — From: or Return-Path?
Return-Path. SPF authenticates the envelope sender, which is often a bounce subdomain or the sending tool's domain. Testing the From: domain gives a verdict no receiver ever computes.
Where do I find the sending IP?
In the message headers, in the Received: line added by the recipient's server — the one closest to the top that says 'from … [IP]'. The header analyzer extracts it for you.
What does permerror mean?
The record is broken: two records, more than ten lookups, an include that points at a domain with no SPF, or an unparseable term. Receivers treat it as no SPF, and DMARC cannot pass on SPF.
Does the tool handle IPv6?
Yes. ip6 mechanisms, AAAA records for a and mx, the //cidr dual syntax, and ip6.arpa reverse lookups for ptr.
Does it expand macros?
No. Terms containing %{…} macros are skipped, because they depend on the sender address and HELO name, which a static test does not have. They are rare outside anti-spam vendors.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.