SPF Record Builder
Build a Sender Policy Framework DNS TXT record for your domain.
Authorised Senders
Policy (all)
DNS TXT Record
v=spf1 mx ~all
Add this as a TXT record on your domain — name: @ (or your domain), TTL: 3600.
What is SPF?
SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send email for your domain. A receiving server checks the connecting server's IP against the record of the envelope sender's domain: the MAIL FROM address given during delivery, or the HELO name when that is empty, which is not always the From address the recipient sees. Each include, a and mx term costs a DNS lookup, and a check that needs more than ten fails outright, so the builder counts the record's own. Use ~all (softfail) when first deploying, then switch to -all (hard fail) once you are confident all legitimate senders are listed. Pair with DKIM and DMARC for full email authentication.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Publishing an SPF record for a domain that sends mail through several services.
- Adding a new sending service to an existing record correctly.
- Choosing between a soft fail and a hard fail policy deliberately.
- Counting the DNS lookups a record's own terms cost before publishing it.
- Catching a mistyped address or a doubled include: before the record goes live.
How it works in practice
A worked example
A small company sends staff mail through Google Workspace and automated alerts from one office server at a fixed IPv4 address, and it wants a strict SPF record that tells receivers to fail everything else.
mx ticked (the default) a unticked (the default) ip4: 198.51.100.25 ip6: (left empty) include: _spf.google.com Policy (all) -all (Fail), changed from the default ~all
v=spf1 mx ip4:198.51.100.25 include:_spf.google.com -all
The builder always writes the terms in one order, mx, a, ip4, ip6, include and then the policy, whatever order the boxes are filled in, and a receiver reads them left to right and stops at the first one that matches. The office server is matched by the ip4 term, which needs no DNS lookup, but only after the mx term has been tried, because that box starts ticked; if no mail leaves through the domain's MX hosts, unticking it spares every check those lookups. The mx term and the include each count as one of the ten DNS-querying terms RFC 7208 allows per check, so the DNS Lookups figure in the stats bar reads 2. It cannot see inside the include, so any lookups Google's own record makes count against the same ten on top of that.
The edge case that catches people
Google's setup page gives its record as v=spf1 include:_spf.google.com ~all. Copying the include term from it, prefix and all, into the include box still gives include:_spf.google.com, because the builder removes a pasted include: before writing its own, and it removes a pasted ip4: or ip6: from those boxes the same way. Pasting the whole record into the include box is different: an include holds one domain name, so a value with spaces in it is flagged against its row and left out of the record until it is fixed. Writing it in would have produced include:v=spf1 followed by two stray terms, and a term the grammar rejects makes the whole record a permerror, so even mail from the office server would no longer pass SPF.
When not to use this tool
The builder resolves nothing in DNS, so its lookup count stops at the record's own terms: it cannot tell whether a record stays within the ten-lookup limit once each include expands into its own includes, or whether a name you typed publishes SPF at all. It offers no redirect=, exists: or exp= terms, so a record that needs one has to be finished by hand. For an inherited record, or one that already names several providers, use a checker that follows every include.
Frequently Asked Questions
- What does an SPF record actually authorise?
- The envelope sender's domain against the sending IP — not the From address a recipient sees. That gap is exactly why DMARC exists: an attacker can pass SPF for a domain they own while putting your domain in the visible From.
- What is the ten-lookup limit?
- SPF allows at most ten terms that need a DNS lookup per check: every
include,a,mx,ptrandexists, plusredirect, counted through every nested include. Going past it is a permanent error that fails the whole record, the commonest way a working SPF quietly breaks after one more provider is added. - Which all mechanism should I use?
~all(softfail) while deploying,-all(hardfail) once the reports show every legitimate sender is covered.?allstates no policy and does nothing useful, and+allauthorises the entire internet, which is worse than having no record at all.- Can a domain have two SPF records?
- No — two TXT records beginning
v=spf1is a permanent error, and evaluators treat it as no valid record. Adding a second provider means merging theirincludeinto the existing record, which is a step people miss when two teams manage DNS. - Does SPF survive forwarding?
- No, and that is its structural weakness. A forwarded message arrives from the forwarder's IP, which your record does not authorise, so SPF fails. DKIM survives forwarding because it signs the message itself, which is why DMARC accepts either passing.
Common errors and gotchas
- Exceeding the ten DNS lookup limit, at which point the record fails and every check with it.
- Publishing more than one SPF record for a domain, which is invalid and fails outright.
- Using
+all, which authorises the entire internet to send as you. - Forgetting a service that sends on your behalf, which then starts failing silently.
- Assuming SPF survives forwarding, which it usually does not — that is what DKIM is for.