SPF Inspector

Look up the SPF record a domain publishes and read it term by term — what each one authorises, the DNS lookups it spends and the policy its all mechanism sets.

Secure server processingWeb & SEOWorkingNo account needed

What this tool does

SPF Inspector is a lookup with a parser waiting behind it. You give it a domain, the OmniKitly service resolves the TXT records published at exactly that name, and the one string beginning v=spf1 comes back to the page, where the reading of it happens. The report opens with the policy, the DNS lookups this record spends out of ten, and its length in characters. A table follows with every term in order: its qualifier written out — + pass, − fail, ~ softfail, ? neutral — the lookups it costs, and what it actually authorises, so an include names the domain it hands off to and an ip4 carrying a prefix gives the number of addresses it opens. Findings and Notes sit underneath, and the raw answer from the service downloads beside them as spf-yourdomain.json.

The lookup figure is the number to read first. A receiver is allowed ten DNS lookups to evaluate one record; include, a, mx, ptr, exists and redirect each spend one, while ip4, ip6 and all spend nothing. Cross ten and the record becomes a permerror, which most receivers treat as no SPF at all — so a domain can authenticate its mail one week, gain a single include for a new marketing tool the next, and stop authenticating anything, with nothing visibly breaking. A warning appears once eight of the ten are gone and an error above ten.

Three limits sit on that number. It covers the terms in this record alone: neither the page nor the service resolves what is inside an include, and include:_spf.google.com carries several lookups of its own, so read the figure as a floor rather than the total a receiver will spend. A note under the report says the true total can only be had by resolving those includes, which nothing here does for you. The parser also checks form rather than fact — it will confirm that ip4:198.51.100.0/24 is well written and never that the range still belongs to you. And a domain publishing two v=spf1 records, or none at all, gets no parsed report: the page falls back to the service's raw JSON, whose own lookup figure is counted by a rougher rule that skips any mechanism carrying an explicit qualifier and adds one for a bare all.

The input field advertises more than the page can run. Its label reads "SPF record — or a domain to look it up", the placeholder offers both, and Load sample drops a complete record into the box — but every run is dispatched to the service as a hostname, so that sample comes back "That is not a valid hostname", refused for the spaces and the equals sign in v=spf1. The parser those controls point at is genuine, and is precisely what writes the report once a lookup has fetched a record; there is simply no route to it by pasting. Enter the domain and what arrives goes through that same code.

No file is involved anywhere in this job — the tool takes a name, not a document. The name you submit reaches the service over an encrypted connection as an ordinary job setting, is written into the job row unredacted, and is swept along with the JSON report at the close of the retention window — six hours after the run unless that default has been changed. The query is made by the service's own resolver, which has two consequences worth carrying: an answer may be served from cache until the record's TTL runs out, so an edit made minutes ago need not show yet, and a failed query is not told apart from an empty one, so a misspelled domain reads exactly like a domain that publishes no SPF record.

How to use it

  1. Enter the domain, not the record. One hostname per run. An http:// or https:// prefix, a path and a port are trimmed off, so https://example.com/contact is queried as example.com — but a space, an equals sign or any non-ASCII character is refused, which means an internationalised domain has to be given in its punycode (xn--) form.
  2. Read the headline, then the table. The first line states the policy, the lookups spent out of ten and the record's length. The table beneath it takes the terms in published order and explains each one. The hint below the output box repeats that verdict with the error and warning tallies.
  3. Work through Findings before Notes. Findings are what the record gets wrong: a malformed ip4 or ip6, a prefix out of range, an unrecognised mechanism, a term stranded after all where it is never evaluated, the deprecated ptr, +all, and the lookup budget. Where there is nothing to report the section shrinks to a single line saying so. Notes are context rather than fault — a record long enough to need publishing as several quoted strings, for one.
  4. Price an include by looking it up too. Run each include target as its own query and add up what they spend. A plain name such as sendgrid.net or spf.protection.outlook.com works; the underscore names — _spf.google.com among them — are refused, because the hostname check accepts only letters, digits, dots and hyphens.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

Chasing an SPF failure named in a bounce

The bounce says the sending address was not authorised. The term list shows what the record does authorise, and whether the service that actually sent the message is represented in it at all.

Adding another sending service

A new include costs a lookup before anything inside it is counted. Reading the current total is what tells you whether there is room for one more or whether something has to be flattened first.

Taking over a domain someone else configured

A record that has collected five years of includes still spends the lookups of services nobody uses any more. Listing the terms is the first step to working out which ones can go.

Checking a domain that should never send mail

A parked or defensively registered name wants a short record ending in -all and nothing else. The report says whether that is what is published; where nothing is, the JSON comes back reading "No SPF record published."

Questions

Is the domain I enter sent anywhere?
Yes. SPF Inspector runs on the OmniKitly processing service rather than in the browser. It arrives as a job setting on an encrypted connection, the TXT query is issued by that machine's resolver, and the job row and its JSON report are swept together once the retention window closes — six hours after the run by default. No file takes part in the job at all, because the tool works from a name.
Why is a pasted record rejected?
Because whatever you type is dispatched as the hostname to resolve, and a record is not a hostname — so a pasted one and the Load sample text alike return "That is not a valid hostname". The parser behind those controls is real and is what produces the report; the only way to reach it is by looking a domain up.
Does the lookup count include what is inside my includes?
No, and nothing in this tool resolves them. The figure counts include, a, mx, ptr, exists and redirect in this record by itself, so treat it as a floor — a single include can spend four or five more on its own. Anywhere near ten, price each target separately before you add anything.
What comes back for a domain with no SPF record?
The parsed report is skipped and the service's raw JSON appears instead, carrying the line "No SPF record published." together with whatever other TXT strings sit at that name. A resolver failure ends the same way, so a mistyped domain and a domain with no record cannot be told apart here — worth ruling out before you conclude anything.
Which name does it query?
Exactly the one you type, with no www or apex fallback. SPF is evaluated against the domain in the envelope sender, and a subdomain does not inherit its parent's record, so a subdomain that sends its own mail has to be looked up in its own right.
Does it check anything beyond the syntax?
No. It reads the record as published — term order, qualifiers, ip4 and ip6 formatting, prefix ranges, ptr, +all, terms left after all, the ten-lookup budget — and stops there. Whether the hosts it authorises are still yours, and whether an include target has quietly grown since you added it, are things the text of a record cannot say.
Does this check DKIM or DMARC too?
No. Those are separate records with separate tools: DKIM Record Checker reads the key published for a selector, and DMARC Inspector reads the policy that decides what a receiver does when SPF or DKIM fails.

Related tools