Free SPF record generator.
Tick the providers that genuinely send mail for the domain, add any extra IP ranges, and copy out one valid SPF record. The reference below covers every mechanism and qualifier you can put in it, and the two mistakes that account for most broken records.
Privacy: this tool runs entirely in your browser. Nothing you type leaves this page, nothing is stored, and nothing is sent to GrowthPal.
Building an SPF record, at a glance
| Item | Value |
|---|---|
| Where it goes | A TXT record at the domain root. Host field @, or blank, depending on the provider |
| How many | Exactly one per domain. A second does not extend the first, it invalidates both |
| Budget | 10 lookup-causing terms. Only ip4, ip6 and all are free |
| How it ends | With an all mechanism. Without one, receivers have no instruction for unlisted senders |
| Record type | TXT. The dedicated SPF record type was deprecated in 2014 and receivers no longer read it |
What goes in an SPF record?
An SPF record is a single line of space-separated terms that names every source allowed to send mail for your domain, followed by an instruction about everyone else. It reads left to right and stops at the first match.
Terms come in two kinds. Mechanisms describe a source: an IP range, a provider's own record, the domain's own A or MX records. Qualifiers sit in front of a mechanism and say what a match means, which is how the same list can authorise some senders and deny others.
The ordering rule matters more than people expect. Because evaluation stops at the first match, a permissive term early in the record can quietly override everything after it. This is why all belongs at the end and nowhere else: put it in the middle and the rest of your record is dead code.
How to read the record this builds
The generator gives you one line plus two notes.
The record itself starts with v=spf1, lists an include for each provider you ticked, then any ip4 or ip6 ranges you added, and ends with an all mechanism.
The placement note tells you where it goes: a TXT record on the domain itself, host field @, value exactly as shown. Not on a subdomain, and not in a record of type SPF.
The merge warning is the one people ignore. If the domain already has an SPF record, this is not a second record to add alongside it. Combine the two by hand into one line, keeping a single all at the end, then publish that.
What the generator cannot know is how many lookups your chosen includes really cost once they expand. Two or three big providers can quietly exceed ten. Check the published record afterwards.
Every SPF mechanism, and what it costs
| Mechanism | What it matches | DNS lookups |
|---|---|---|
ip4: | An IPv4 address or CIDR range sending directly. | 0 |
ip6: | An IPv6 address or range. | 0 |
a / a:domain | The A or AAAA records of the domain, or of a named one. | 1 |
mx / mx:domain | The hosts in the domain's MX records. Each evaluation is itself capped at 10 address lookups. | 1 |
include: | Another domain's SPF record, evaluated in full. The nesting inside it counts too. | 1, plus whatever it nests |
exists: | Whether a constructed name resolves at all. Used with macros for per-sender logic. | 1 |
ptr | Reverse DNS on the connecting IP. Valid but the spec says SHOULD NOT be used. | 1, and slow |
all | Everything. Matches whatever reached it, so it belongs last. | 0 |
redirect= | Hands evaluation to another domain's record entirely. Not a mechanism, a modifier. | 1 |
The four qualifiers
| Qualifier | Result on match | Use it for |
|---|---|---|
+ | pass | The default. Never written out, because every unprefixed mechanism already means this. |
- | fail | The end state. -all once you are certain the sender list is complete. |
~ | softfail | The safe default while you are still finding stray senders. ~all. |
? | neutral | Almost nothing. ?all tells a receiver you have no opinion, which is worse than saying nothing. |
How to publish an SPF record and confirm it works
- List every real sender first. Your sending platform, your mailbox provider if humans send from the domain, and any transactional service. Anything that does not genuinely send should not be in the record.
- Check for an existing record. Look for a TXT record starting
v=spf1. If one exists, you are editing it, not adding to it. - Create one TXT record at the root. Host
@or blank. Paste the value exactly, with no surrounding quotes added by hand; most DNS panels add their own. v=spf1 include:_spf.google.com ip4:192.0.2.0/24 ~all - Wait for propagation. Up to an hour on a typical TTL, sometimes less.
- Verify the published record. Run the domain through the SPF checker and confirm the lookup count is inside 10 and the
allmechanism is what you intended. - Tighten to
-allwhen you are sure. Once a few weeks pass with no legitimate sender failing, move from~allto-all.
Common questions about building an SPF record
Can a domain have two SPF records?
No. Two TXT records starting v=spf1 produce a permerror and receivers ignore both, so adding a second one does not extend the first, it breaks it. Merge every sender into one record with a single all mechanism at the end.
How do I know which providers to include?
Anything that genuinely sends mail as this domain: your sending platform, Google Workspace or Microsoft 365 if your team uses it, plus transactional senders like billing or support tooling. Every include you add that does not really send spends one of your ten lookups and widens who is allowed to send as you.
Where exactly does the record go?
In a TXT record at the root of the domain, with the host field set to @ or left blank depending on your DNS provider. Not in a record of type SPF; that type was deprecated in 2014 and receivers no longer read it. Allow up to an hour for DNS, then confirm it resolves.
Do I need SPF on a domain that only sends and never receives?
Yes, that is exactly the case SPF exists for. The record is published by the domain doing the sending and read by the servers receiving. A sending domain without one is among the most common reasons a warmup batch never reaches the primary inbox.
Does the order of mechanisms matter?
Yes, because evaluation stops at the first match. A permissive term early in the record overrides everything after it, which is why all belongs at the end and nowhere else. Put it in the middle and every term behind it is dead code that will never be read.
Should I use ip4 ranges instead of include?
Where the provider publishes stable addresses, yes, because ip4 costs no DNS lookups and include costs at least one. The trade is maintenance: when the provider changes its ranges, your record is silently wrong. Use ip4 for infrastructure you control and include for providers you do not.
Tools check the plumbing. The message is what your market answers. Get your TAM mapped, your ICP broken down and 5 angles written for your buyers, free.