SPF record generator
Runs in your browser
SPF says which servers are allowed to send mail using your domain. The syntax is small; the part that catches people is a limit of ten DNS lookups that is counted across everything your record refers to. Answer the questions and this builds the record and counts as it goes.
It is built in this page, on your machine. Nothing you type is uploaded, and nothing here queries DNS — this writes a record, it does not check one.
Build a record
Add at least one sender above and the record will appear here.
The parts that are easy to get wrong
Ten lookups, and what counts
RFC 7208 §4.6.4 caps a record at ten DNS-querying mechanisms. Each include:, a, mx, ptr, exists: and redirect= costs one. ip4: and ip6: cost nothing, because the answer is already in the record.
Go over and the result is permerror, which receivers treat as a failure, not as a warning. A record eleven lookups deep does not degrade gracefully — it stops authorising anything, including the mail that was working yesterday.
The counter on this page counts what you declare. It cannot see inside an include:, and the domains behind a large provider frequently contain several of their own. Four includes can easily be twelve real lookups. To know your total you have to resolve the record, which is a DNS query and is therefore a different tool from this one.
-all, ~all and where to start
-all is a hard fail: everything not listed is unauthorised. ~all is a soft fail, which receivers generally accept and weigh against everything else they know. ?all is neutral and decides nothing.
Start at ~all while you are still discovering who sends your mail, and move to -all once the reports stop surprising you. The order matters: publishing -all before you have listed the invoicing tool nobody remembered is how real mail starts bouncing.
+all is not offered here, and this page reports it as a mistake if a record contains it. It authorises the entire internet to send as your domain — the same as publishing nothing, except that it looks deliberate.
One record, not several
A domain may publish exactly one SPF record. Two v=spf1 TXT records is a permerrorand breaks both. When you add a provider you extend the existing record; you do not add a second one, however much the provider’s documentation reads as though you should.
Anything after the first all is unreachable, so a record with two of them does not mean what whoever wrote it thought.
SPF alone proves very little
SPF authorises the envelope sender — the address bounces go to — and a reader never sees that address. A sender can hold a perfect SPF pass on their own bounce domain while the From line says something else entirely.
DMARC is what ties the authorised domain to the one the reader sees, so SPF without DMARC is a check nobody is applying to the thing that matters. If you are setting up SPF for the first time, do DKIM and DMARC in the same sitting.
Where it goes
A TXT record on the domain itself, with no prefix — not on _spf, which is only where providers publish the records you include. A subdomain that sends mail needs its own record; a subdomain that does not should publish v=spf1 -all, which is the strongest thing a non-sending name can say.
One of the free email tools.