Free tool · Email auth
SPF record generator
Pick the services that send mail on your behalf and get a syntactically-correct SPF record you can paste into the apex TXT record. Real-time DNS-lookup counter so you know before you publish if you'll trip the RFC 7208 10-lookup cap.
Pick the services that send mail on your behalf
One include: directive per service. Each is one DNS lookup against the SPF cap.
Advanced (optional)
-allis the right answer once your senders are settled - rejects everything that didn't match a mechanism above. ~allis a softer cutover phase used while you're still discovering who sends on your behalf.
Your SPF record
v=spf1 include:_spf.google.com -all
Where it goes: create a TXT record at the apex of your domain (e.g. example.com with name @). One SPF record per domain - merging into an existing one is required, never publish two.
Verify after publishing: run the DMARC checker (it surfaces SPF as part of the same report) or paste the new record into the SPF raw validator.
What this tool checks
What an SPF record does: tells receiving mail servers which IPs (or named services) are authorised to send mail with your domain in the SMTP envelope. A receiver does an SPF check, finds your record at the apex TXT, walks the mechanisms, and either accepts the sender (pass), defers it (softfail), or rejects it (fail) depending on the terminator you set.
The 10-lookup cap: RFC 7208 limits an SPF evaluation to 10 DNS lookups. Every include:, a, mx, ptr, and exists mechanism counts; ip4: and ip6: do not. Cross the cap and receivers return permerror - essentially the same outcome as not having SPF at all. Our counter shows the running total as you tick boxes; once you breach 10 the generator points you at the SPF flattener which collapses includes into raw ip4: / ip6: entries.
One record per domain: publishing two SPF records on the same name produces permerror. If you already have an SPF record, merge the include: tokens from this generator into the existing one rather than adding a second TXT.
How to read the results
-all = reject anything not explicitly listed. Right answer in steady state. Pair with DMARC p=reject and you have the strongest authentication posture.
~all= soft-fail. Receivers accept but mark the message (often delivered to spam). Useful as a cutover phase while you're still discovering all the things that send on your behalf - typically 2 weeks at ~all, then flip to -all once your DMARC aggregate reports confirm no legitimate senders are getting marked.
?all = neutral. Receivers accept and do nothing special. Rarely the right answer; almost always a misconfiguration. +allmeans "trust everyone" - never publish this; it tells the world anyone can spoof your domain.