Pick the services that send email for your domain and get one valid SPF record, with the DNS lookups counted live so it stays inside the limit of ten.
An SPF record is a single line of text in your DNS that lists every server allowed to send email for your domain. Receiving mail servers compare the sending server against that list, and mail from anywhere else can be marked as suspicious or rejected.
Most domains need more than one entry: a mailbox provider such as Google Workspace or Microsoft 365, plus a newsletter tool, a help desk, maybe an invoicing system. This generator combines them into one valid record and counts the DNS lookups as it goes, because that count is where most SPF records quietly break.
Every service you sign up for tells you to "add our SPF record", and the natural thing is to add a new TXT record each time. That is the most common SPF mistake there is. The standard (RFC 7208) allows exactly one SPF record per domain, and when a receiver finds two it must return a permanent error rather than pick one. Two correct records add up to a broken one.
The fix is to merge them. Each service gives you an include: value; all of them go into a single record that starts with v=spf1 and ends with one all mechanism. That is exactly what this tool builds.
Checking an SPF record costs the receiver DNS queries, so the standard caps them at ten. Every include:, a, mx, ptr, exists and redirect counts as one, and the count is recursive: if a provider's include itself contains three more includes, you pay for all four. ip4:, ip6: and all are free.
Go over ten and receivers return a permanent error, which most treat the same as having no SPF at all. Nothing tells you this has happened. The record still looks fine, mail still sends, and some of it starts failing authentication. That is why this generator resolves every include live and shows the real total, instead of assuming each provider costs one.
If you are near the limit, remove services you no longer use first. After that, the usual option is replacing an include with the ip4: ranges it currently lists, which costs nothing, but you then have to notice when the provider changes those ranges. Treat that as a last resort.
The record ends with what to do about every server you did not list. ~all (soft fail) asks receivers to accept the message but treat it with suspicion. -all (fail) asks them to reject it. ?all (neutral) expresses no opinion and gives almost no protection.
Start with ~all while you are still discovering services that send on your behalf: a forgotten contact form, an accounting tool, a printer that emails scans. Once a DMARC policy is reporting and the reports show everything legitimate passing, move to -all. In practice DMARC decides what happens to failing mail for most large receivers, so the choice matters less than having the record right.
Bulk sending services such as Amazon SES, SendGrid, Mailgun and Postmark usually send with their own bounce address (the "envelope sender" or return-path), and SPF is checked against that address, not against the From address your readers see. In that setup the receiver never looks at your SPF record, so adding their include just spends lookups.
The include matters when you configure a custom return-path or MAIL FROM domain on your own domain. Each provider's setup page says which applies. Either way, what actually protects that mail is DKIM signing with your domain plus DMARC, so set those up first.
Parked domains and web-only domains are popular with spammers precisely because nobody watches them. If a domain should never send mail, publish v=spf1 -all, which says that no server is allowed to send for it, and pair it with a DMARC record of v=DMARC1; p=reject. Leave every box unticked above and the generator produces that record.
No. The standard allows exactly one, and receivers must treat two or more as a permanent error, which means SPF fails for every message. Merge everything into a single record that starts with v=spf1 and ends with one all mechanism.
There is no limit on includes as such, but the whole record may trigger at most ten DNS lookups, and includes inside includes count too. A large provider can cost three or four lookups on its own, which is why this generator counts them live.
In the DNS settings for your domain, wherever the domain's nameservers are hosted (often your registrar, Cloudflare or your web host). Add a TXT record with the name @ (meaning the domain itself) and the generated value. If a v=spf1 record already exists, edit it rather than adding a second one.
Usually minutes, but receivers may keep the old answer until its TTL expires, which is often an hour and can be up to a day. You can confirm what the world sees with our DNS propagation check.
No. The SPF standard itself says ptr should not be used: it is slow, unreliable and costs lookups. Use ip4:, ip6: or an include from your provider instead.
No. SPF checks the hidden envelope sender, not the From address people see, and it breaks when mail is forwarded. DKIM signs the message itself, and DMARC ties both to the visible From address and tells receivers what to do with failures. You want all three.