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, a sender that receivers need an eleventh lookup to find gets permerror and loses its pass. We resolve the full chain of the record you pasted, the same way a receiver does, and show the total above. The SPF 10-lookup limit guide covers how to get the number down.

Not on its own. You can have as many include: terms as you like, as long as they cost no more than 10 lookups between them. 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 adds them without touching the rest. Paste the result here to see what 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. We can't expand them from the record alone, so their addresses aren't in any total on this page. When one is present, you'll see a + after each count, because the real number can be higher. Dropping an mx can cost you a sender even when the address counts on both sides stay the same, so read the list of terms as well as the totals.

The result shows what DNS returned when you ran the check. The includes in your record belong to other companies, and they add and remove address ranges without telling you. If you make the edit tomorrow, run the check 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 adds them to the record your 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.