How to Add an SPF Record in Cloudflare DNS
By VigilDog Team · August 26, 2026 · 6 min read
An SPF record tells the world which servers are allowed to send email for your domain, and getting it wrong is a quiet way to land in spam. Adding an SPF record in Cloudflare takes about two minutes in the dashboard — but the value you type matters far more than the clicks. Here is how to do both parts correctly.
What SPF does, and the one-record rule
SPF (Sender Policy Framework) is a single TXT record on your domain listing the mail servers authorized to send on its behalf. When a receiving server gets your mail, it checks the sending IP against this list and uses the result as one input to deciding whether to accept, junk, or reject the message.
The rule that trips people up: a domain may have exactly one SPF record. Two `v=spf1` records is not additive — it is a permanent error that most receivers treat as no policy at all. Everything below assumes you are creating or editing that single record.
Adding the record in Cloudflare, step by step
In the Cloudflare dashboard:
- Select your domain, then open the DNS → Records section.
- Click Add record and choose type TXT.
- Set Name to @ (this is the root/apex of your domain, e.g. example.com).
- Set Content to your SPF string, starting with v=spf1 — for example `v=spf1 include:_spf.google.com ~all` for Google Workspace.
- Leave TTL on Auto; SPF does not need a special TTL. (Proxy status does not apply to TXT records.)
- Save, then confirm there is no second TXT record beginning with v=spf1.
Getting the record value right
Your SPF string is a space-separated list of mechanisms. The common ones are `include:` (authorize another provider's servers, like Google or Microsoft 365), `ip4:` / `ip6:` (authorize a specific address or range), and `mx` / `a` (authorize the hosts in your MX or A records). Add one `include` per sending service — your email host, plus anything else that sends as your domain, such as a marketing platform or support desk.
The record ends with an `all` mechanism that sets the default for everything not listed. `~all` is a softfail (accept but mark as suspicious) and `-all` is a hardfail (reject). Start with `~all` while you confirm every legitimate sender is covered, then tighten to `-all` once you are confident nothing is missing.
The mistakes that quietly break SPF
Two problems cause most SPF failures. The first is the duplicate record already mentioned — always edit the existing SPF record rather than adding a new one. The second is the 10-lookup limit: SPF allows at most ten DNS-querying mechanisms (`include`, `a`, `mx`, `ptr`, `exists`, `redirect`) to be resolved. Exceed it and the record returns a permerror, which many receivers treat as a failure.
It is easy to blow past ten when several providers each nest their own includes. If you are near the limit, remove senders you no longer use, and prefer flattening only as a last resort since flattened IP lists go stale when a provider changes infrastructure. If you are also fixing DKIM and DMARC, work through them together with our guide on fixing SPF, DKIM and DMARC.
Verify it, then connect it to DMARC
DNS changes in Cloudflare propagate quickly, but give it a few minutes, then confirm the record resolves and passes with our DMARC checker or a `dig TXT example.com` lookup. If TXT records in general are new territory, DNS records explained covers how they fit together.
SPF alone does not protect your domain from spoofing — it authorizes servers, but DMARC is what ties SPF and DKIM to the visible From address and tells receivers what to do on failure. Once SPF passes cleanly, add DMARC so the three work as a system.