The SPF Record Generator is a four-step wizard, and each step is made of input cards with a What's this? link in the corner. This article is the long-form version of those pop-ups: one section per card, in the order the wizard asks for them, with the same control rendered inline so you can see exactly which field is being described. Where a card offers a choice, select an option in the preview and the explanation for that specific choice appears underneath.
acme-corp.com. IN TXT "v=spf1 mx ip4:198.51.100.24 include:_spf.google.com -all"
│ │ │ │ └── Step 4 — policy
│ │ │ └── Step 3 — third-party senders
│ │ └── Step 2 — authorised IPs
│ └── Step 2 — your own servers
└── the version tag, always firstDomain
The first field in the wizard, and the only one that is genuinely required. It decides where the record is published and which mail the record speaks for.
SPF is checked against the domain in the envelope sender — the Return-Path the sending server announces in MAIL FROM — not the From: address your recipients see. For most organisations these are the same domain, which is why entering the domain you send from is the right answer. When a mailing platform uses its own bounce domain, SPF is evaluated against that domain, and alignment becomes DMARC's problem rather than SPF's.
Unlike DMARC, the record does not live on a _prefix subdomain. It is published at the root of the domain itself, as a TXT record with host @.
v=spf1 on the same name is a permanent error (permerror), and receivers treat the domain as having no usable policy at all rather than merging them. If you already publish one, merge the mechanisms into a single record.Look up existing queries the domain's live SPF record and shows it back to you. When one is found the wizard swaps in a second card offering to prefill every step from it:
A domain that never sends mail should still get a record — v=spf1 -all — so nobody can send as it. Parked domains and redirect-only domains are a favourite target precisely because they are usually left unprotected.
Already have a record?
The optional paste card on step 1. It reads any v=spf1 string back into the wizard so you can edit a record rather than rebuild it from memory.
Parsing sets every step below it:
aandmxtick the matching switches in step 2.- Each
ip4:andip6:becomes a row in the IP list. - Recognised
include:targets tick their provider card; anything else lands in “other include domains”, so nothing is silently dropped. - The qualifier on
allselects the policy in step 4.
The card disappears once a lookup succeeds, because the “Record found” card above does the same job with the domain's real record. Neither one publishes anything — prefilling only fills in the form.
Your own mail servers
Step 2 opens with the two mechanisms that authorise servers already named in your DNS, rather than by address. Select either card in the preview to see when it belongs in your record.
Both mechanisms are resolved at delivery time, which is their advantage and their cost: change your MX records and SPF follows automatically, but every message triggers a fresh DNS lookup against the limit of ten. On a record that is already close to the ceiling, replacing mx with explicit ip4: mechanisms buys back a lookup.
Authorized IP addresses
The second card in step 2 lists sending addresses literally. Each row becomes one ip4: or ip6: mechanism; the wizard picks the right one from the format you type.
Because the value is already an address, a receiver does not have to resolve anything — these are the only mechanisms that cost no DNS lookup. That is what makes them the standard fix for a record that has outgrown the limit: take the vendor's published ranges and inline them instead of including their record.
A bare address authorises exactly one host. CIDR notation authorises a block: ip4:192.0.2.0/24 covers 256 addresses. Be deliberate about the prefix length — a careless /16 can hand authorisation to an entire hosting provider, including whoever else rents space in it.
include: and save lookups elsewhere.Third-party senders
Step 3 is where most real-world SPF problems live. Every service that sends mail as your domain — the mail host, the CRM, the invoicing tool, the marketing platform, the helpdesk — needs to be authorised, or its mail fails SPF. The quick-pick grid covers the common ones; ticking a card adds that provider's documented include target.
An include: does not copy the provider's addresses into your record — it tells the receiver to evaluate the provider's own SPF record as part of yours. That is why the provider can rotate their sending infrastructure without you touching DNS, and why the mechanism is worth its cost.
The cost is real, though. Each include is one DNS lookup, and the includes nested inside it count too. include:_spf.google.com alone resolves to three further includes, spending four of your ten lookups on a single provider. Two or three big platforms is all it takes to hit the ceiling.
| Mechanism | Costs a lookup? | Typical use |
|---|---|---|
ip4: / ip6: | No | Your own static sending addresses |
a | Yes — 1 | A web or app server that sends directly |
mx | Yes — 1 | Servers that both receive and send |
include: | Yes — 1 plus everything it nests | Third-party platforms |
redirect= | Yes — 1 | Delegating to a shared policy |
all | No | Always the last thing in the record |
Other include domains
The free-text card for any sender that is not in the quick-pick grid. Enter the include target the provider documents — not their website, and not their MX host. Separate several with commas; the wizard adds the include: prefix itself.
If you are unsure what a vendor needs, search their documentation for “SPF” — they will name the exact hostname to include. Pasting a full include:vendor.com works too; the prefix is stripped rather than doubled.
Audit this field whenever you drop a vendor. Stale includes are pure cost: they keep spending lookups, and they keep authorising a platform that may have handed your former sending IPs to someone else.
Policy for everyone else
Step 4 closes the record. The all mechanism decides what a receiver should do with mail from a server that matched nothing above it, and it must be the last thing in the record — anything after it is never evaluated. Select a policy below to see what it means in practice.
There is a fourth qualifier, +all, which authorises the entire internet. It is never a legitimate configuration and the wizard does not offer it. If you ever see it on a live domain, that domain is effectively broadcasting permission to be spoofed.
~all while aggregate reports are still turning up senders you forgot, then move to -all once a few weeks of reports come back clean.Delegate the policy
The advanced card at the bottom of step 4. Turning it on replaces the all mechanism with a redirect= modifier pointing at another domain.
redirect= hands the entire decision to the target domain: the receiver evaluates that record instead of yours, including its all mechanism. That is why a record may carry redirect= or all, but never both — the wizard greys the policy cards out while the toggle is on.
# Centrally managed policy, published once
spf.example.com. IN TXT "v=spf1 mx include:_spf.google.com -all"
# Every brand domain points at it
brand-a.com. IN TXT "v=spf1 redirect=spf.example.com"
brand-b.com. IN TXT "v=spf1 redirect=spf.example.com"This is worth it when you run dozens of domains that should share one policy — update the shared record and every domain follows. For a single domain it adds a DNS lookup and a layer of indirection for no benefit; close with all instead.
What the wizard does with your answers
Pressing Generate record assembles the mechanisms in the order receivers expect —a and mx, then IPs, then includes, then the policy — and runs the result through a validation checklist covering the lookup count, the record length, the presence of a terminating mechanism and the strength of the policy you chose. The result panel also carries the exact DNS fields to enter: host @, type TXT, the generated value.
Nothing is published for you. Copy the record into your DNS provider, then confirm it with the SPF Lookup tool once the TTL has passed.
Frequently Asked Questions
1. Which fields are actually required?
Only the domain. Everything else is optional in the sense that the wizard will still produce a valid record — but a record with no sending mechanisms and -all is a statement that the domain sends no mail at all, which is correct for parked domains and wrong for everything else.
2. Do I need both mx and ip4 for the same server?
No, and doing so wastes a lookup. If the server is already in your MX records, mx covers it. Use ip4: instead of mx when you want to save the lookup and the address is stable.
3. Why is my provider not in the quick-pick list?
The list covers the platforms that come up most often. Anything else goes in the “other include domains” field — the resulting mechanism is identical, since a quick-pick card is only a shortcut for typing the same include target.
4. What happens if I exceed ten lookups?
Evaluation stops with a permerror and the message is treated as if SPF failed to produce a result — which, under a DMARC policy, is a failure. The wizard counts the mechanisms you add so you can see the budget before you publish, but it cannot see inside a third party’s record, so verify the final total with the SPF Lookup tool.
5. Should subdomains get their own SPF record?
SPF does not inherit. A subdomain that sends mail needs its own record at mail.example.com, and a subdomain that never sends should publish v=spf1 -all. Run the wizard again with the subdomain in the domain field.