SPF change pre-flight
Paste the SPF record you are about to publish. We resolve it against the one the domain serves today and list what would stop being authorised, while the change is still in your clipboard.
What a pre-flight check tells you that a checker cannot
What does this page do? It resolves the SPF record your domain publishes right now, resolves the record you pasted as if it were already published, and reports the difference: which address ranges stop being authorised, which start, where the DNS lookup count lands, and what the ending does to everything the record does not name.
A record about to break your mail looks like one that is not: correct syntax, plausible includes, an ending somebody chose on purpose. The checkers on this site, and everywhere else, read what DNS is serving, so they can only answer once the edit is live and the first bounce has arrived. This one answers while the record is still in your clipboard.
A dropped include is invisible until the invoices stop
An include: nobody can account for comes out of the record, and the platform behind
it is still sending. The record stays valid, so nothing rejects the edit; SPF returns fail where
it returned pass, and under -all a receiver turns that fail into a bounce. The
ranges that lose their authorisation are listed above with the mechanism each one came from,
which is how the include you could not place turns out to be the one your billing system sends
through.
The lookup count moves for the same invisible reason. It is spent across everything nested inside your includes rather than the terms you can see, so an edit that looks like it adds one line can add four lookups, and past ten the whole record is a permerror. The ten-lookup guide covers what to do about that number; the count above is taken from the proposed record with its full chain resolved, which is the same arithmetic a receiver does.
What it cannot see, and says so
The a, mx, exists and ptr mechanisms, and any
term containing a macro, authorise whatever they resolve to when a message arrives. No reading of
a record expands them, so the addresses under them are in no total on this page. Where one is
present every count is labelled as a floor, and a change that turns on one of them is reported as
a partial comparison: dropping an mx can cost you a sender while the address counts
either side of the change stay identical.
The comparison is also a snapshot. It is what DNS served in the second the check ran, and the includes in your record belong to other people, who add and remove ranges without telling you. A diff that was clean this morning is evidence about this morning.
Whose domain, and what to do next
Any domain. It reads public DNS, the same as a receiving mail server does, so a consultant can pre-flight a change on a client's domain before the change window opens, without an account and without access to anything.
If the record still has to be written rather than checked, the SPF record generator builds one from your senders and splices it into what the domain publishes today. Afterwards, the SPF checker reads the live record back and the combined checker covers the other two records, since SPF is the half that a forwarded message breaks. The syntax reference covers what each mechanism costs.
The senders a diff cannot check for you
This page compares two records. Whether the ranges one of them drops are still carrying mail is a question only the reports answer: they name each host that sent under your domain and whether it passed. On a paid plan, a failing sender your reports have never named before turns into an email the same day. On Pro, one Monday email covers 10 domains for $19 a month.
Start watching your sendersNo card · 12+ months of history · The free plan does not expire