Domain
Who sends for this domain
Tick only the services that send from this domain. A sequencer that logs into your Google or Microsoft mailbox does not need its own include — the mail leaves through that provider.
Direct senders
Enforcement
Your record
How it works
ip4, ip6, all
Free. Addresses are already in the record, so the receiver reads them and moves on.
a, mx, exists
One lookup each, every time the record is evaluated.
include
One for the include itself, plus every lookup inside it. Google costs about four on its own.
Load what you publish
Start from the current record so you can see what you are changing rather than guessing.
Tick real senders only
Every include you add for a service that does not actually send costs a lookup and buys nothing.
Watch the counter
The count shown is direct terms. Run the result through the lookup counter for the true recursive total.
Publish as TXT
Host @ or the bare domain, type TXT, TTL 3600. One SPF record per domain — never two.
Only one SPF record, ever
A domain may publish exactly one TXT record starting v=spf1. Publishing two is the single most common way to break SPF outright: receivers see the ambiguity and return permerror, and a permerror is not a soft failure — it takes the whole evaluation down, and DMARC with it if you were relying on SPF for alignment.
This is easy to do by accident. You add Google Workspace, publish a record. Months later somebody adds a marketing platform and publishes a second one rather than editing the first. Both look correct in isolation. If you are merging senders, they all belong in one record, separated by spaces.
The ten-lookup limit is a hard ceiling
SPF permits ten DNS-querying mechanisms per evaluation. include, a, mx, ptr, exists and redirect all count. ip4, ip6 and all do not.
The trap is that includes nest. include:_spf.google.com looks like one lookup in your record, but it expands into three further includes, so it costs about four of your ten before you have added anything else. Three or four providers is genuinely enough to blow the limit. The counter above shows direct terms only, because the real total depends on what each provider publishes today — feed the finished record into the SPF lookup counter to expand it properly.
When you are over, the fix is not to delete senders you need. Replace includes with the ip4 ranges behind them where the provider publishes stable addresses, or flatten the record. Both trade maintenance for headroom, so keep a note of what you flattened and when.
-all or ~all
-all tells receivers to reject anything from an unlisted source. ~all tells them to accept it but mark it as suspicious. In practice most large receivers treat the two similarly once DMARC is at enforcement, because DMARC is where the real decision now happens.
The honest guidance is this: ~all while you are still discovering who sends for you, -all once you are confident the list is complete. Going straight to -all on an established corporate domain is how the invoicing tool nobody remembered stops delivering. On a fresh sending domain with one provider, there is nothing to discover and -all is fine from day one.
What cold email tools actually need
Most sequencers — the ones that connect to your Google Workspace or Microsoft 365 mailbox over OAuth or SMTP — send through that provider. The mail leaves Google’s servers, so include:_spf.google.com already authorises it. Adding a separate include for the sequencer authorises infrastructure that never touches your mail and spends a lookup you will want later.
The exception is a tool with its own sending infrastructure, where mail leaves the vendor’s IPs rather than your mailbox. Those do need an include, and the vendor will tell you which. If you are not sure which kind you have, check where the mail actually originated with the header analyzer — the first Received hop settles it.
Subdomains do not inherit
Unlike DMARC, SPF has no inheritance. A record on yourdomain.com does nothing for mail.yourdomain.com. If a subdomain sends mail, it needs its own record. If it does not send, publish v=spf1 -all on it so the absence is explicit rather than merely undefined.
Frequently asked questions
Where does the SPF record go?
On the domain itself — host @ or the bare domain name depending on your DNS provider, type TXT. Not on a subdomain like _spf. If your provider asks for a name and you enter spf, you will publish it at spf.yourdomain.com where nothing will ever read it.
Can I have two SPF records?
No. A domain must publish exactly one record beginning v=spf1. Two produces a permanent error at the receiver, which fails SPF entirely rather than falling back to either record. Merge every sender into a single record.
Does SPF alone stop spoofing?
No. SPF validates the envelope sender, which the recipient never sees — the visible From header can say anything. That gap is exactly what DMARC alignment closes, which is why SPF without DMARC offers far less protection than people assume.
What happens if I exceed ten lookups?
Receivers return permerror and most treat it as an SPF failure. If DMARC is relying on SPF for alignment and DKIM is not also passing, the message fails DMARC and your policy is applied to your own legitimate mail.
Should I use ptr?
No. The ptr mechanism is deprecated, slow, and explicitly discouraged by the specification. Some receivers ignore it entirely. If a provider tells you to add it, use their published ip4 ranges instead.
Do I need SPF if I already have DKIM?
Publish both. DMARC passes on either one aligning, so two authenticated paths means one can break without your mail failing. They also fail differently — SPF breaks on forwarding, DKIM survives it but breaks when a mailing list rewrites the body.
What TTL should I use?
3600 seconds is a reasonable default. Drop it to 300 while you are actively changing senders so mistakes roll back quickly, then raise it once the record has settled.
Why is my record too long?
A single TXT string caps at 255 characters. Longer records must be split into multiple quoted strings, which receivers concatenate. Most DNS providers do this for you; a few require you to enter the chunks yourself. If you are near the cap you are also probably near the lookup limit, which is the more urgent problem.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.