How to Set Up an SPF Record: Step-by-Step Guide
A step-by-step guide to setting up an SPF record: find your sending sources, build the record, publish it at your DNS provider, and verify it with an SPF checker.
How to Set Up an SPF Record: Step-by-Step Guide
TL;DR To set up an SPF record: (1) identify every service that sends email for your domain, (2) build a TXT record listing them, (3) publish it at your DNS provider, and (4) verify it looks correct. An SPF record is a single TXT record at your domain root — you can have exactly one.
What SPF Does
An SPF record tells receiving mail servers which IP addresses and services are authorized to send email on behalf of your domain. Without it, anyone can send email that claims to be from your domain. With it, receiving servers can check whether the sending server is on your approved list and reject or flag messages that aren't.
For a conceptual overview of how SPF works, see What Is an SPF Record?.
Step 1: Identify Every Service That Sends Email for Your Domain
Before writing a single character of SPF, make a complete list of everything that sends email using your domain in the From: or envelope sender address.
Common sending sources:
- Your mail provider — Google Workspace, Microsoft 365, Zoho Mail, Fastmail, Proton Business
- Transactional email — SendGrid, Mailgun, Postmark, Amazon SES, SparkPost
- Marketing email — Mailchimp, HubSpot, Klaviyo, ActiveCampaign, Constant Contact
- CRM and sales tools — Salesforce, HubSpot CRM, Outreach, Salesloft
- Support platforms — Zendesk, Intercom, Freshdesk
- Your own mail servers — if you run your own SMTP server, you need its IP
Why this step matters: every service you miss will have its emails fail SPF. If you add a service later, you need to update your SPF record. Build the complete list now.
How to find what you're missing
Check your domain's existing TXT records — if SPF is already partially configured, you can see what's already included:
dig example.com TXTAlso ask your team — marketing, sales, and support tools are often added without IT involvement.
Step 2: Build Your SPF Record
SPF records are TXT records that start with v=spf1 and end with an all mechanism. In between, you list your authorized senders.
Include statements for major providers
Most email service providers publish their own SPF record that you reference with include:. Check your provider's documentation for the exact include value. Common ones:
| Service | SPF include |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |
| Postmark | include:spf.mtasv.net |
| Amazon SES (US East) | include:amazonses.com |
| Mailchimp | include:servers.mcsv.net |
| HubSpot | include:hubspotemail.net |
| Zendesk | include:mail.zendesk.com |
IP addresses for your own servers
If you run your own mail server, add its IP directly:
ip4:203.0.113.10 # Single IPv4 address
ip4:203.0.113.0/24 # IPv4 CIDR range
ip6:2001:db8::1 # IPv6 addressThe all mechanism
End every SPF record with one of:
~all— softfail: mail from unlisted sources is accepted but marked suspicious. Safe starting point.-all— hardfail: mail from unlisted sources is rejected. Use this once you're confident your record is complete.?all— neutral: no policy. Provides no protection — don't use it.
Assemble the record
Combine everything into a single space-separated string:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~allImportant: you can only have one SPF record per domain. If you have multiple services, combine them into a single record — multiple v=spf1 records cause a PermError.
Watch the 10-lookup limit
SPF has a hard limit of 10 DNS lookups during evaluation. Each include:, a, and mx mechanism counts as one lookup — and includes can nest. If you exceed 10 lookups, SPF returns PermError and the check fails.
Count your includes before publishing. If you're at or near 10, consider:
- Replacing
include:with directip4:entries where possible (some providers list their IPs) - Using an SPF flattening service that pre-resolves includes to IP ranges
DNS Buddy's SPF Checker expands your full include chain and counts lookups, so you can see the depth before and after making changes.
Step 3: Publish the Record at Your DNS Provider
Log into your DNS provider (wherever you manage your domain's DNS — your registrar, Cloudflare, Route 53, etc.) and create a TXT record:
| Field | Value |
|---|---|
| Name / Host | @ (or leave blank, or your domain name — depends on the provider) |
| Type | TXT |
| Value / Content | Your SPF record string, e.g. v=spf1 include:_spf.google.com ~all |
| TTL | 3600 (or your provider's default) |
Provider-specific notes
Cloudflare: Enter @ for the Name field. Paste the record value without quotes.
AWS Route 53: The record value must be wrapped in double quotes: "v=spf1 include:_spf.google.com ~all".
GoDaddy / Namecheap: Use @ or leave Name empty. Some interfaces show the domain name — don't repeat it.
Google Domains / Squarespace: TXT records go under "Custom records." Use @ for the host.
Existing SPF record: If a TXT record starting with v=spf1 already exists, edit it rather than adding a second one. Two SPF records = PermError.
Step 4: Wait for Propagation
DNS changes don't take effect immediately. New TXT records propagate based on the TTL. If your domain's default TTL is 3,600 seconds, allow up to an hour before checking.
During propagation, some resolvers may still see the old record. If you're verifying shortly after publishing, query your authoritative nameserver directly to confirm the record was saved:
# Replace ns1.example.com with your actual nameserver
dig @ns1.example.com example.com TXTStep 5: Verify Your SPF Record
Once propagated, verify the record looks correct and is valid.
Check with DNS Buddy
Use DNS Buddy's SPF Checker to:
- Confirm the record was published and is visible from public resolvers
- See the full expanded include chain
- Get a lookup count (must be ≤ 10)
- Identify which IP ranges are authorized and which providers they belong to
Check with dig
dig example.com TXT | grep spfThe output should show your record. If nothing appears, propagation may still be in progress, or the record wasn't saved correctly.
Send a test email
After verifying the record looks correct, send a test email to an address you control at Gmail or another provider. In Gmail, open the message, click the three-dot menu, select "Show original," and look for the Authentication-Results header:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of user@example.com designates
203.0.113.10 as permitted sender) ...spf=pass confirms the check succeeded. spf=fail or spf=softfail means something is still wrong.
Common Mistakes
Multiple SPF records
The most common setup error: adding a second TXT record starting with v=spf1 instead of editing the existing one. Always edit — never add a second.
# Wrong — two SPF records
example.com TXT "v=spf1 include:_spf.google.com ~all"
example.com TXT "v=spf1 include:sendgrid.net ~all"
# Right — one combined record
example.com TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"Missing a sending service
If a service sends email on your behalf but isn't in your SPF record, those emails will fail SPF. Common ones people forget: CRMs, support ticket systems, bulk email tools, and automated notification services.
Exceeding 10 DNS lookups
Adding too many include: statements, especially ones that chain to other includes, can push you over the 10-lookup limit. Check the lookup count before and after changes with DNS Buddy's SPF Checker.
Using +all or ?all
+all means "authorize everyone" — it provides no protection. ?all means "no policy" — same problem. Always use ~all or -all.
Publishing SPF on a subdomain that doesn't send mail
If you have subdomains that never send email (noreply.example.com, mail.example.com), publish v=spf1 -all for them — an SPF record with nothing authorized. This prevents spammers from exploiting your unused subdomains.
After Setup: Add DKIM and DMARC
SPF alone is not enough for reliable email deliverability and spoofing protection.
- DKIM adds a cryptographic signature to outgoing email. Unlike SPF, DKIM survives email forwarding. Most providers generate the DKIM key for you and give you a TXT record to publish.
- DMARC ties SPF and DKIM together. It lets you specify what to do when both checks fail, and provides reporting on who is sending email using your domain.
Publishing all three (SPF + DKIM + DMARC) is the current standard for business email. Major inbox providers (Gmail, Yahoo, Microsoft) are increasingly requiring all three for reliable delivery.
Frequently Asked Questions
How do I know if my SPF record is working?
After publishing, use DNS Buddy's SPF Checker to confirm the record is visible and valid. Then send a test email and check the Authentication-Results header in the received message. 'spf=pass' means it's working.
Can I set up SPF without a mail provider?
Yes. If you want to prevent any email from being sent on behalf of your domain (e.g., a domain you own but don't use for email), publish: v=spf1 -all. This tells receivers to reject all email claiming to be from your domain.
What if my mail provider isn't in the table above?
Check your provider's documentation for their SPF include value. Search for '[provider name] SPF record' — almost all email service providers publish their include value in their help docs.
Do I need an SPF record for subdomains?
Each subdomain that sends email needs its own SPF record — subdomains don't inherit from the parent domain. Subdomains that never send email should have 'v=spf1 -all' to prevent spoofing.
How long does it take for an SPF record to work after publishing?
Propagation depends on your TTL. With a default TTL of 3600 seconds (1 hour), allow up to an hour. You can query your authoritative nameserver directly to confirm the record was saved before propagation completes.
Related
- What Is an SPF Record? — SPF syntax reference and how it works
- DKIM Record — set up DKIM alongside SPF
- DMARC Record — add DMARC for full email authentication
- Free SPF Checker — verify your record after setup
- TXT Record — how TXT records work in DNS