How to Add SPF Record to Your Domain: Every DNS Host
The mechanics of how to add SPF record protection to a domain take about five minutes: it is one TXT record in your DNS. What fills support queues is everything around those five minutes - adding the record at the wrong company, adding a second record instead of merging into the first, or putting the wrong thing in the cryptic Host field. This walkthrough covers the procedure at the major DNS hosts, the merge patterns for domains that send through more than one service, and the verification step that confirms it worked.
One orientation fact first: SPF lives with whoever runs your DNS - which is usually your domain registrar or Cloudflare, and is not necessarily your email provider. Google or Microsoft tell you what the record should say; the record itself gets created wherever your nameservers point.
Step 1: get the value, then check what already exists
Your email provider's documentation gives you the exact string. The common ones:
- Google Workspace:
v=spf1 include:_spf.google.com ~all - Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all - A sending platform (newsletter, transactional, CRM): the
include:hostname from its setup page.
Before adding anything, look up what your domain already publishes - in a terminal, nslookup -type=TXT yourdomain.com (or dig TXT yourdomain.com), or any online SPF lookup. This step exists because of the single most damaging mistake in this whole topic: a domain may only have one SPF record. Two TXT records starting v=spf1 don't cooperate - together they produce a permanent error that receivers treat as no SPF at all, instantly degrading mail that used to authenticate fine. If a record already exists, you are merging, not adding.
Step 2: merging, when you send through more than one service
Merging means placing the new provider's include: (or ip4:) inside the existing record, before the final all token. Existing Google record plus a new sending platform:
Before: v=spf1 include:_spf.google.com ~all
After: v=spf1 include:_spf.google.com include:_spf.sendprovider.example ~all
Microsoft 365 plus an office server with a fixed IP:
v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all
Keep v=spf1 once at the front, keep exactly one all at the end, and be aware of the ten-DNS-lookup budget shared by all your includes - if the domain has accumulated five or six services, audit for dead ones while you're in there rather than piling on.
Step 3: how to add SPF record entries, host by host
The fields are the same everywhere - Type TXT, Host/Name for the bare domain, Value the SPF string, TTL left at default. What differs is what each host calls the bare domain:
| DNS host | Where | Host/Name field for the root domain | Quirks |
|---|---|---|---|
| Cloudflare | DNS → Records → Add record | @ |
Proxying doesn't apply to TXT; paste value without quotes |
| GoDaddy | Domain → DNS → Add New Record | @ |
Shows existing TXT records in the same list - check before adding |
| Namecheap | Domain List → Manage → Advanced DNS | @ |
Choose "TXT Record", not the legacy "SPF" type if offered |
| Squarespace Domains | Domains → DNS Settings → Custom Records | @ (or blank) |
Hosts former Google Domains registrations |
| Amazon Route 53 | Hosted zone → Create record | leave name empty | Value must be wrapped in double quotes; type TXT, never the deprecated SPF type |
| cPanel hosting | Zone Editor → Manage | the full domain, often auto-appended | Watch for the editor auto-appending your domain to whatever you type |
Universal rules across all of them. Use record type TXT - a dedicated "SPF" record type still offered by some panels is a deprecated relic that receivers ignore. In the Host field, @ means "the domain itself"; typing your full domain there on hosts that auto-append produces the broken yourdomain.com.yourdomain.com. And quotes: some panels add them automatically, some require them (Route 53), most want the raw string - if your saved record displays with doubled quotes, remove yours.
Subdomains are separate. SPF is checked at the domain that appears in the envelope sender. If a system sends as something@mail.yourdomain.com, the TXT record belongs at Host mail, and the root record does not cover it. This is common with sending platforms that use a dedicated subdomain - their setup instructions will name the exact host value.
Step 4: verify, then finish the job
DNS changes propagate anywhere from minutes to a few hours (48 is the theoretical worst case; modern hosts are usually near-instant). Verify twice:
- The record resolves: run the same
nslookup/diglookup and confirm the new string comes back, once, with no siblingv=spf1record. - Real mail passes: send a message from the actual service to a Gmail address, open it, choose Show original, and read
SPF: PASS- and check which domain it passed for. Platforms that send from their own bounce domain will pass SPF on that domain rather than yours, which is normal, and is precisely the alignment question DMARC exists to police.
If mail misbehaves right after the change
The record is trivially reversible, which makes debugging low-stakes: edit it back and DNS forgets within the TTL. The two symptoms worth recognizing are a sudden permerror in message headers - almost always a second v=spf1 record or a typo like include= instead of include: - and legitimate mail from some overlooked system starting to softfail, which means that system now needs its own place in the record. Neither symptom deletes mail on a ~all policy; both show up plainly in Show original, so re-test from each sending service after any edit rather than assuming.
Two closing cautions. First, SPF alone is the floor, not the finish: DKIM (your provider's signing keys, also DNS records) and a DMARC policy are the other two-thirds of the authentication stack that Gmail and Yahoo now expect, and each is a similar one-record errand. Second, resist the urge to end a brand-new record with -all before you've inventoried every system that sends as your domain - the billing tool and the ancient contact form count. Run ~all for a couple of weeks while you watch for legitimate mail failing, then tighten. A record added carefully once beats one repaired publicly twice.
Frequently asked questions
Where do I add an SPF record?
At whichever company runs your domain's DNS - your registrar, Cloudflare, or your web host - not inside your email provider. The email provider only supplies the string; the TXT record is created where your nameservers point.
What goes in the Host or Name field for an SPF record?
@ (or an empty field, host depending) for the root domain. Only use a subdomain name when a service actually sends from that subdomain - SPF is checked at the exact domain in the envelope sender.
How long does an SPF record take to work?
Usually minutes at modern DNS hosts, up to a few hours in the worst case. Verify with a TXT lookup, then send a real message to Gmail and confirm SPF: PASS under Show original.
I already have an SPF record - how do I add another service?
Merge, never add a second record: place the new service's include: inside the existing record before the final all token. Two records starting v=spf1 produce a permanent error treated as no SPF at all.