SPF change pre-flight

Lookups are spent inside your includes, not on the lines you can see. One new include: can pull in four more lookups from the includes nested under it. Past 10 the whole record returns permerror and every sender in it loses its pass. The count above resolves the full chain of your pasted record, which is the same arithmetic a receiver does. The SPF 10-lookup limit guide covers how to get the number down.

Not on its own. Nothing caps how many include: terms a record carries; the 10 lookups they cost between them is the cap. Four includes can come to four lookups or to fifteen, depending on what each provider nests inside its own record, and you can't tell which from reading your line. Paste the combined record and the count above resolves the whole chain.

No. A domain publishes one. Two v=spf1 records on the same name is a permerror, and a permerror costs every sender in both records its pass, so the new one doesn't work and the old one stops working too. A new sender's terms go inside the record that's already there. The SPF record generator splices them in without touching the rest, and pasting the result here shows what the splice changed.

With -all, unlisted senders fail SPF. With ~all, unlisted senders get an SPF softfail. DMARC treats both results as an SPF failure. The receiver decides whether to accept or reject the mail. +all passes everyone. Check that the record lists every sender you use before changing the ending.

The a, mx, exists and ptr mechanisms, and any term with a macro in it, resolve when a message arrives. No reading of the record expands them, so their addresses aren't in any total on this page. Where one is present, every count is marked as a floor. Dropping an mx can cost you a sender while the address counts on both sides stay the same, so read the mechanism list as well as the tiles.

It's a snapshot. It shows what DNS served the second the check ran. The includes in your record belong to other people, and they add and remove ranges without telling you. A clean diff this morning is evidence about this morning. If the edit waits until tomorrow, run it again first.

Yes. If your DNS records live in a repository, our free GitHub Action sends each proposed record to this check and fails the pull request when the change would break SPF. The SPF pull request guide covers the setup, with a recipe for octoDNS, DNSControl and Terraform.

Yes. The check reads public DNS, the same as a receiving mail server does. A consultant can check a client's change before the change window opens. No account is needed.

Use both, in that order. The SPF record generator builds the record from your senders and splices it into what the domain publishes today. Paste the result here to see what it changes. Once it's live, the SPF checker reads it back, and the combined checker covers DKIM and DMARC as well.