Email authentication
SPF record generator
Build a valid SPF record from the senders you actually use, and see the DNS-lookup cost before you publish it.
Free, no accountIn your browser
Comma-separated. Only for servers you run yourself, not a provider ticked above.
Comma-separated.
A domain name only, without "include:" - for a sender not in the list above.
Result
RFC 7208 §4.6.4 caps the whole chain at 10.
Record ready to publish
Copy the record below into a TXT record at the root of the domain.
- Passed
0 of 10 DNS lookups used
There is room to add more senders later without approaching the 10-lookup ceiling RFC 7208 §4.6.4 sets.
SPF record to publish
At @ (TXT)
Publish this as a TXT record at the domain itself, not a subdomain.
- The lookup cost for each sender ticked above is the chain depth published in that provider’s own SPF documentation at the time this was written - a provider can change its own record, which changes the cost without anything changing here.
- A domain you typed into "Any other provider’s include" is counted as one lookup, which is a floor: if that domain itself includes others, the true cost is higher. Check its own SPF record with the SPF checker before publishing.
What this is
This SPF record generator turns a checklist of senders into a valid SPF record, and does the one calculation that is otherwise invisible until a record breaks: how many of the ten DNS lookups RFC 7208 §4.6.4 allows the chosen senders will actually spend.
Every mailbox provider, marketing platform and helpdesk that sends mail "from" your domain needs to be named in its SPF record, as an "include" that points at that provider's own list of servers. Leaving one out does not stop its mail sending - it stops that mail from passing SPF, which many receivers treat as a reason to doubt the whole message.
What a checklist cannot show by itself is cost: each provider's include is its own DNS lookup, and some providers' own records include others again. Google Workspace, for instance, spends four lookups once its own chain is followed, not the one line this tool writes for it.
How to read the result
The counter at the top says how many of the ten allowed lookups the ticked senders spend. Below eight it is undramatic; from eight it is worth noticing before adding anything else, and past ten the record is invalid before it is even published - RFC 7208 §4.6.4 makes every mechanism in it meaningless once that happens.
The record itself goes in a TXT record at the domain’s own name, never a subdomain, and a domain publishes exactly one of them - adding a second SPF record rather than editing this one is itself a fault the SPF checker next door will flag.
Common mistakes
What goes wrong most often, and how to tell.
- Listing a provider’s servers as ip4 ranges instead of its includeA provider's sending ranges change without telling every customer first. Its "include" mechanism always points at its current list; copying today's ranges into your own record freezes them at today, and they go stale the next time the provider adds a server.
- Not knowing an include’s own cost before adding itA provider's own SPF record can include others of its own, so one line here can spend more than one of the ten lookups the record is allowed. Four well-known providers can add up to the limit faster than four lines suggests.
- Choosing +all to avoid troubleshooting a failureThis passes every sender, listed or not, which erases the point of listing any of them. A failure is almost always one real sender missing from the list above, not a reason to let every sender through.
- Publishing the record on a subdomain instead of the domain itselfSPF is checked against the domain in the return-path address, which for most mail is the domain itself. A record published on "mail.example.com" instead of "example.com" is never read for ordinary mail from that domain.
Questions
What people ask about this tool.
- Tick both in the checklist above: each gets its own "include" mechanism in the same record, in any order, ending with one "all" mechanism that covers everyone not explicitly listed.
- A provider's "include" mechanism points at that provider's own SPF record, and that record can include others of its own. Google Workspace's chain, for example, spends four lookups once followed all the way down, not one.
- No - a domain is only allowed one "v=spf1" TXT record, and RFC 7208 §4.5 treats a second one as a permanent error that breaks checking entirely. Reduce the lookup cost instead, by removing a sender or flattening an include.
- "~all" is the safer starting point: it flags an unlisted sender without rejecting its mail outright, which matters while you are still confirming nothing real was left off the list. Move to "-all" once you are confident the list is complete.
Use it from the API
The same check, as one request.