An SPF (Sender Policy Framework) record is a DNS TXT record that lists every server and service authorised to send email from your domain. Without one, receiving mail servers have no way to verify that your messages are legitimate — and many will send them straight to spam.
SPF lets the receiving server check whether the IP address that delivered an email is listed as authorised in your domain's DNS. If it isn't, the server can flag the message as suspicious or reject it outright.
Step 1: Identify Every Service That Sends Email for Your Domain
Before writing a single character, audit all the services that send email using your domain. Missing even one will cause legitimate messages to fail SPF checks. Common senders include:
- Your mail server — the primary server your company uses (e.g. Google Workspace, Microsoft 365, Zoho).
- Marketing platforms — Mailchimp, Klaviyo, HubSpot, Brevo, and similar tools.
- Transactional email providers — SendGrid, Postmark, Amazon SES, Mailgun.
- CRM and helpdesk tools — Salesforce, Zendesk, Intercom, Freshdesk.
- Your own web servers — any server running scripts that send email directly.
- Third-party SaaS tools — any other platform that sends on your behalf.
Check your existing DNS records and ask your team. Look through sent-mail headers for unfamiliar relay domains or IP addresses.
Step 2: Understand the SPF Record Syntax
An SPF record is a TXT record published at the root of your domain. It always starts with v=spf1 and ends with an all qualifier that defines what happens to mail from unlisted sources:
~all— softfail: accept the mail but mark it as suspicious (recommended while testing).-all— hardfail: reject mail from unlisted sources (recommended for production).?all— neutral: no opinion (not recommended; provides no protection).+all— pass everything (never use this; it defeats the purpose of SPF).
Common mechanisms you can include in the record:
include:domain— inherit the SPF record of a third-party service.ip4:x.x.x.xorip4:x.x.x.x/24— authorise a specific IP or CIDR range.ip6:...— authorise an IPv6 address or range.a— authorise the IP addresses in the domain's own A records.mx— authorise the domain's MX servers.
Step 3: Build Your SPF Record
Combine the mechanisms for every service you identified in Step 1. Here is a typical SPF record for a domain that uses Google Workspace for email and SendGrid for transactional messages:
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"If you also have a dedicated mail server with a static IP address, add it with the ip4 mechanism:
example.com. IN TXT "v=spf1 ip4:203.0.113.42 include:_spf.google.com include:sendgrid.net ~all"SPF allows a maximum of 10 DNS lookups during evaluation. Each include:, a, mx, and ptr mechanism counts as one lookup. Exceeding this limit causes an SPF permerror, which many receivers treat as a failure. Count your mechanisms carefully and flatten nested includes where possible.
Step 4: Add the TXT Record to Your DNS
Log in to your DNS provider (your domain registrar, Cloudflare, Route 53, etc.) and create a new TXT record with the following settings:
| Field | Value |
|---|---|
| Type | TXT |
| Host / Name | @ (or leave blank — represents the root domain) |
| Value / Content | Your full SPF record string, e.g. v=spf1 include:_spf.google.com ~all |
| TTL | 3600 (1 hour) or your provider's default |
Important: a domain must have exactly one SPF record. If you already have a TXT record starting with v=spf1, edit it rather than creating a second one. Multiple SPF records cause a permerror.
Step 5: Verify with the ShowDNS TXT Lookup Tool
Once you've saved the record, wait a few minutes for DNS propagation, then confirm it is live using the ShowDNS TXT Lookup tool. Enter your domain and look for the TXT record beginning with v=spf1. It should match exactly what you entered.
You can also query via the command line. The dig command is available on Linux and macOS; nslookup works on all platforms including Windows:
# Using dig (Linux / macOS)
dig TXT example.com +short
# Using nslookup (Windows / macOS / Linux)
nslookup -type=TXT example.comThe output should include a line like "v=spf1 include:_spf.google.com ~all".
Step 6: Test End-to-End Email Delivery
Viewing the record in DNS confirms it was published — but you also need to verify that mail actually passes the SPF check. Use any of these methods:
- Mail-tester.com — send an email to the address mail-tester generates, then view your SPF (and overall spam) score.
- Check email headers — send yourself a test email, open the raw headers, and look for
Authentication-Results: spf=pass. - MXToolbox SPF validator — paste your domain to check the record parses correctly and count lookups.
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of hello@example.com designates
203.0.113.42 as permitted sender)
smtp.mailfrom=hello@example.comCommon SPF Mistakes to Avoid
- Publishing two SPF records — merge them into one. Two records cause a permerror and break authentication entirely.
- Using
+all— this authorises every IP on the internet to send as you. Never do this. - Exceeding 10 DNS lookups — audit your
include:chains and use IP ranges directly where possible. - Forgetting subdomains — SPF only covers the exact domain it is published on. Create separate records for subdomains that send email (e.g.
mail.example.com). - Using
~allpermanently — softfail is good for testing but switch to-allonce you're confident the record is complete. Softfail alone does not prevent spoofing.
Start with ~all (softfail) when you first publish your SPF record. Monitor email headers for a week to ensure no legitimate senders are missing. Once you're confident the record is complete, switch to -all (hardfail) for stronger protection against spoofing.
Frequently Asked Questions
Can I have multiple SPF records on the same domain?
No. RFC 7208 requires exactly one SPF TXT record per domain. If you need to authorise multiple services, combine all the mechanisms into a single record. Publishing two records produces a permerror that causes SPF to fail entirely.
Does SPF alone stop email spoofing?
SPF checks the envelope sender address used during the SMTP conversation — not the From: header visible to the recipient. Attackers can spoof the visible From header while passing SPF. You need DKIM and DMARC alongside SPF for complete spoofing protection.
How long does it take for an SPF record to propagate?
DNS changes typically propagate within a few minutes to a few hours, depending on your TTL setting and the resolver's cache. Most providers apply changes within 5–30 minutes. Use the ShowDNS TXT Lookup tool to check propagation from multiple locations.
What is the difference between include: and redirect= in SPF?
include: incorporates the mechanisms from another domain's SPF record and continues evaluating the rest of your record. redirect= replaces your entire SPF record with another domain's policy — it is only useful when you want to delegate SPF management entirely to another domain. Most people should use include:.
Do I need SPF if I already have DKIM?
Yes. SPF and DKIM are complementary, not interchangeable. DMARC — the policy layer that actually blocks spoofed mail — requires at least one of SPF or DKIM to pass and align with the From domain. Having both gives you redundancy and is required for DMARC enforcement.