SPF record generator
Pick the platforms that send mail as your domain. We build the record and count the DNS lookups as you go, because that is the limit records break on.
Who sends mail as this domain?
IPv4 or IPv6, space separated. These cost no DNS lookup, which is why a fixed sending IP is cheaper than an include.
Any other include your provider gave you.
What should receivers do with mail from anywhere else?
Start on soft fail. Move to hard fail once your DMARC reports show nothing legitimate is failing.
Your SPF record
v=spf1 ~all0 of 10 DNS lookups
Counted from this record alone. Each include spends more inside its own record, so check the real total with the SPF checker once it is published.
- This record lists no senders. As written it says nothing may send as this domain. That is correct for a parked domain and wrong for one you mail from.
| Where it goes | Value |
|---|---|
| Record type | TXT |
| Host / name | @ (the domain itself) |
| TTL | 3600 is fine |
One SPF record per domain. If one already exists, edit it rather than adding a second: two records is a permanent error and receivers will ignore both.
Publishing it without breaking today's mail
One rule above all the others: a domain gets exactly one SPF record. If a record already exists, edit it. Adding a second TXT record that starts with v=spf1 is a permanent error under the spec, and receivers are entitled to ignore both, which takes a domain from partial authentication to none.
Publish with ~all first. Soft fail asks receivers to accept mail from senders you did not list while flagging it, so the system nobody remembered keeps working while you find it.
Then wait, and read. DNS propagation is quick, and discovering your own senders is not. A month covers a monthly billing run; two weeks does not. Once the reports are quiet, tighten to -all.
Watch the lookup count as you add platforms. Google Workspace spends four on its own, and four includes is where most domains start to feel the ceiling. An ip4 term costs nothing, so a provider that publishes stable addresses can often replace an include.
| Step | What to do | How long |
|---|---|---|
| Publish | One TXT record on the domain, ending in ~all | Minutes |
| Observe | Read DMARC aggregate reports for unlisted senders | Four to six weeks |
| Fix | Add the senders you find, or stop them sending as you | As needed |
| Tighten | Change ~all to -all once reports are clean | Minutes |
Subdomains need their own record
SPF does not inherit. A record on example.com says nothing about mail from news.example.com, and a receiver checking that subdomain finds no record and treats it as unauthenticated.
That matters most for the marketing subdomain, which is usually where the highest volume goes. Each sending subdomain needs a record naming its own platform, and a subdomain that sends nothing should carry v=spf1 -all for the same reason a parked domain does.
Questions people ask
Can I list the same provider twice?
There is no reason to, and it costs a lookup each time. If two of your tools send through the same platform, one include covers both.
My provider gave me an include and an IP range. Which do I use?
The include, unless you are short on lookups. The include keeps working when the provider changes its addresses; a hardcoded range quietly stops authorizing mail the day they renumber.
Does the order of mechanisms matter?
Evaluation stops at the first match, so putting your most common sender early saves the receiver work. The all mechanism must come last, because everything after it is ignored.
What if I exceed ten lookups and cannot remove anything?
Flatten the busiest include into the ip4 ranges behind it and accept that you now have to maintain it, or move some sending to a subdomain with its own record. Both are chores, and both beat a permerror.
A published record is not a clean list
Authentication decides whether receivers trust the sender. Verification decides whether the recipient is there at all, and reports the addresses nobody can settle.