What goes into an SPF record
An SPF record is a single TXT entry listing every source allowed to send mail as your domain, terminated by a policy for everyone else. A company using Google Workspace for corporate mail, Mailchimp for newsletters, and one self-hosted server ends up with:
v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.5 ~allThree kinds of terms do the work. include: delegates to a provider's own SPF record, so their IP changes never require you to touch DNS again. ip4: and ip6: authorize addresses you control directly. The final ~all sets the policy for unlisted senders. The generator above builds exactly this shape, in the conventional order: a/mx first if you use them, then IPs, then includes, then the all-qualifier.
Decisions the form is making for you
Includes over raw IPs for ESPs. You could copy your ESP's current IP ranges into ip4: terms and save DNS lookups. You would also inherit a maintenance duty forever, because ESPs rotate ranges without notice. The include exists so the vendor maintains the list; use IPs only for servers you administer.
The lookup counter. Each include, plus a and mx if checked, costs one DNS lookup against the limit of 10 from RFC 7208 — and includes nest. The counter under the generated record shows top-level lookups only, which is why it warns early, at six. The true count needs the whole include tree resolved; paste your published record into the SPF checker and it will walk the tree for you.
~all as the recommended start. A hard -all on day one is how invoices from the billing system you forgot about start silently failing. Soft fail keeps imperfect knowledge survivable. Tighten once reporting proves the list complete.
a and mx unchecked by default. Most modern setups send through an ESP or a mail host, not from the web server or the inbound MX hosts. Each of those mechanisms costs a lookup and usually authorizes nothing that sends. Check them only when the machine behind your A record or your MX hosts genuinely submits outbound mail.
Publishing and verifying
Copy the record, open your DNS provider's panel, and create a TXT record with host @ and the record as the value. Two cautions. First, check for an existing v=spf1 record before saving — if one exists, merge the mechanisms into it rather than adding a second record, because duplicate SPF records fail as a permerror. Second, TTL: if your zone default is long, drop it to 300–3600 seconds while testing so mistakes don't linger for a day.
After the record propagates, verify it from the outside: run your domain through the SPF checker to confirm syntax, count the full lookup tree, and catch anything the form could not know about your existing DNS. Then send a test message to a Gmail address and read the Authentication-Results header — spf=pass with your domain is the confirmation that matters.
SPF is one leg of three. The same pass in a Gmail header will show dkim and dmarc results next to it, and senders need all three aligned to satisfy the 2024 Gmail and Yahoo bulk-sender rules. Generate your DMARC record with the DMARC generator, and if you are still choosing the platform that will sit behind that include, our deliverability rankings show which services actually reached the inbox in our tests — method and dates included, per the methodology.
Frequently asked questions
Where do I publish the generated SPF record?
As a TXT record on the domain itself — in most DNS panels that means host @ (or blank), type TXT, value starting with v=spf1. Not on a subdomain like mail.example.com unless you send from that subdomain, and never as the deprecated SPF record type.
I already have an SPF record. Can I add a second one?
No — two SPF records is a permerror under RFC 7208 and receivers treat it as if you had none. Merge instead: take the mechanisms from this generator's output (everything between v=spf1 and the all term) and add them to your existing record before its all mechanism.
Which all-qualifier should I pick?
~all (soft fail) to start: unauthorized mail is marked suspicious but not refused, so a source you forgot doesn't vanish. Once DMARC reports confirm every legitimate sender is covered, tighten to -all. Avoid ?all, which asserts nothing, and never publish +all.
Are the ESP include values here always correct?
They are the widely documented values as of when we curated the list, and vendors do restructure their SPF hosts over time. Treat the dropdown as a head start, and confirm the exact include in your provider's own DNS setup page before publishing. That page is authoritative; ours is convenience.
Does this generator send my data anywhere?
No. It is a static form — the record is assembled in your browser and no domain names, IPs or selections leave the page. The checkers on this site do perform server-side DNS lookups; the generators don't need to.