You send a perfectly crafted email to a client, partner, or customer — and it vanishes into their spam folder. No bounce, no error, just silence. Nine times out of ten, a missing or broken SPF record is the culprit. SPF (Sender Policy Framework) is the DNS-based mechanism that tells the world which mail servers are authorized to send email on behalf of your domain. Without a valid SPF record, receiving mail servers have no way to verify your legitimacy, and spam filters treat your messages with deep suspicion. This guide walks through exactly what SPF is, why it fails, and how to fix it — fast.
What Is an SPF Record and Why Does It Matter
SPF is a type of DNS TXT record published in your domain's DNS zone. When a receiving mail server gets a message claiming to be from you@yourdomain.com, it queries DNS for your domain's SPF record and checks whether the sending server's IP address is listed as an authorized sender. If the IP matches, the check passes. If it does not, the message may be marked as spam, quarantined, or outright rejected, depending on how strict the receiving server is.
The practical impact is significant. Gmail, Microsoft 365, and virtually every major mail provider factor SPF alignment into their spam scoring. Domains without a valid SPF record consistently see higher spam placement rates, lower deliverability, and in some cases complete rejection. If you are running a business domain and sending transactional email, marketing campaigns, or even routine correspondence, SPF is not optional — it is foundational.
Anatomy of an SPF Record
An SPF record is a single DNS TXT record at your root domain (or subdomain) that follows a strict syntax. Here is a realistic example for a domain that sends through Google Workspace and a third-party email platform like Mailchimp:
Breaking that down:
- v=spf1 — declares this is an SPF version 1 record. Always required, always first.
- include:_spf.google.com — authorizes all IP addresses that Google publishes for its outbound mail servers.
- include:servers.mcsv.net — authorizes Mailchimp's sending infrastructure.
- ~all — the catch-all qualifier. A tilde means "soft fail" — treat unauthorized senders with suspicion but do not outright reject. A hard fail (-all) instructs receivers to reject unauthorized mail. A permissive pass (+all) is essentially useless and dangerous.
Other common mechanisms you will encounter:
- a — authorizes the IP address(es) in the domain's A record.
- mx — authorizes the IP addresses of the domain's mail exchangers.
- ip4:203.0.113.50 — explicitly authorizes a specific IPv4 address.
- ip6:2001:db8::/32 — explicitly authorizes an IPv6 range.
- redirect=otherdomain.com — delegates the entire SPF policy to another domain.
The Most Common SPF Mistakes That Send Email to Spam
No SPF Record at All
The most common failure. If your domain has never had an SPF record configured, every piece of mail you send goes out without authorization. Run a quick check using the DNS Lookup tool — search for TXT records on your root domain. If you do not see a record starting with v=spf1, that is your problem.
Multiple SPF Records
This is a silent killer. Many domains accumulate multiple TXT records starting with v=spf1 over time — one added by the original admin, another added when a new email service was set up, a third from a marketing platform. SPF explicitly forbids multiple records for the same domain. RFC 7208 states that if more than one SPF record exists, the result is a PermError, which most receiving servers treat as a failure. You must merge all mechanisms into a single record.
Exceeding the 10 DNS Lookup Limit
Every include:, a, mx, and redirect= mechanism triggers a DNS lookup when the receiving server evaluates your SPF record. SPF allows a maximum of 10 such lookups. Exceed that limit, and the evaluation results in a PermError. Domains that use many third-party sending services — a CRM, a marketing platform, a ticketing system, a transactional email provider — frequently hit this ceiling. The fix is to use SPF flattening or consolidate senders.
Forgetting Third-Party Senders
If you send email through Mailchimp, Salesforce, HubSpot, SendGrid, Twilio, Zendesk, or any similar service and you have not added their SPF include mechanism, those messages will fail SPF checks. Every platform you use to send email on behalf of your domain needs to be authorized in your SPF record.
Using ~all When You Should Use -all
A soft fail (~all) is often fine during initial setup, but if you have confirmed all legitimate sending sources, upgrading to -all sends a clear instruction to reject unauthorized senders. Staying on ~all indefinitely means spam filters are less confident in your policy, which can still hurt deliverability.
Step-by-Step: Creating or Fixing Your SPF Record
Step 1 — Audit Your Current DNS
Before touching anything, know what is already there. Query your domain's TXT records:
Look for any records starting with v=spf1. Note how many there are and what mechanisms they contain. If there are two or more, you need to merge them.
Step 2 — Identify Every Service That Sends Email for Your Domain
Make a list. Common categories include:
- Your primary mail provider (Google Workspace, Microsoft 365, Zoho Mail, Fastmail)
- Marketing platforms (Mailchimp, Klaviyo, Campaign Monitor, HubSpot)
- Transactional email (SendGrid, Postmark, Mailgun, Amazon SES)
- CRM and support tools (Salesforce, Zendesk, Freshdesk, Intercom)
- Your own web server or application if it sends notifications or password resets
Each of these services publishes documentation on what include mechanism or IP range to add. Look it up for each platform before proceeding.
Step 3 — Construct Your Merged SPF Record
Combine all mechanisms into a single TXT record. Example for a domain using Microsoft 365, SendGrid, and a dedicated web server IP:
Keep it as tight as possible. Avoid the a and mx mechanisms unless you genuinely need them — they add lookups. Prefer explicit ip4: entries for individual servers when the IP is static.
Step 4 — Publish the Record in DNS
Log into your DNS host or registrar — this could be Cloudflare, GoDaddy, Namecheap, Route 53, or wherever your DNS zone is managed. Add or update the TXT record:
- Name/Host: @ (or leave blank, depending on the panel — this represents the root domain)
- Type: TXT
- Value: your complete SPF string
- TTL: 3600 (one hour is fine; lower it to 300 before making changes, raise it after confirming the fix)
If you are replacing an existing record, delete the old one first. Do not add a second SPF record alongside the existing one.
Step 5 — Verify Propagation and Correctness
DNS changes can take minutes to an hour to propagate globally. Use the DNS Propagation Checker to confirm your new TXT record has spread across major resolvers worldwide before testing deliverability.
You can also test SPF validation directly from the command line by looking at what the receiving server sees. Send a test email to a Gmail account and view the original message headers. Look for the Authentication-Results header:
An spf=pass result confirms everything is working. An spf=fail or spf=softfail result means the sending IP is still not authorized, and you need to revisit Step 2 and 3.
Dealing With the 10 DNS Lookup Limit
If you are using four or more third-party sending services, you are at real risk of hitting the SPF lookup limit. Here is how to diagnose it and fix it.
Count the lookups manually: each include:, a, mx, and exists mechanism counts as one lookup. But each of those includes may themselves reference additional includes — those count too. Google's SPF record, for example, currently resolves to several sub-lookups internally.
The cleanest fix is SPF flattening: resolve all the includes down to their underlying IP addresses and replace the includes with explicit ip4: and ip6: entries. This reduces lookup count to zero (IP address entries do not trigger DNS lookups). The downside is maintenance — if a provider changes their IP ranges, your flattened record becomes stale. Some services like dmarcian, EasyDMARC, and Valimail offer automated SPF flattening as a managed service to handle this automatically.
SPF Alone Is Not Enough
SPF is one leg of a three-part email authentication framework. For best deliverability, you need all three:
- SPF — confirms the sending server is authorized by the domain owner.
- DKIM (DomainKeys Identified Mail) — adds a cryptographic signature to each message, verifying it has not been tampered with in transit.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) — ties SPF and DKIM together, specifies what to do with failures, and provides reporting so you can see who is sending email on behalf of your domain.
Without DMARC, even a passing SPF check can still leave you vulnerable to domain spoofing in certain scenarios. DMARC also introduces the concept of alignment — the domain in the email's From header must align with the domain that passed SPF or DKIM. This is what closes the gap that bad actors try to exploit.
If you are currently fighting spam placement issues, set up SPF first, then DKIM through your mail provider's control panel, then add a DMARC record starting with a permissive policy (p=none) to gather reports before enforcing.
How to Prevent SPF Problems in the Future
- Document every authorized sender. Keep an internal record of which platforms send email for your domain and what SPF mechanism each requires. When you add a new service, update your SPF record before you start sending.
- Set a calendar reminder to audit. SPF records go stale. Quarterly, verify that every include in your record still applies and that no new services have been onboarded without updating DNS.
- Lower TTL before changes, raise it after. A TTL of 300 seconds before making DNS changes means you can quickly fix a mistake. Once you have verified the new record works, raise TTL back to 3600 or higher.
- Monitor with DMARC reports. A p=none DMARC policy generates aggregate reports (RUA) that show you every IP address sending mail with your domain in the From header. This is the best early warning system for both configuration drift and spoofing attempts.
- Never use +all. A permissive catch-all essentially tells the world that anyone can send as your domain. It is never correct for a production domain.
Quick Reference: Common Provider SPF Includes
- Google Workspace: include:_spf.google.com
- Microsoft 365: include:spf.protection.outlook.com
- Zoho Mail: include:zoho.com
- SendGrid: include:sendgrid.net
- Mailgun: include:mailgun.org
- Mailchimp / Mandrill: include:servers.mcsv.net
- Amazon SES: include:amazonses.com
- HubSpot: include:hubspotemail.net
- Salesforce: include:_spf.salesforce.com
- Postmark: include:spf.mtasv.net
Always verify these against each provider's current documentation — includes do change, and using an outdated mechanism can fail silently.
Final Check Before Moving On
Once your SPF record is published and verified, send a test message to check-auth@verifier.port25.com — a free service that replies with a detailed authentication report showing SPF, DKIM, and DMARC results. You can also use mail-tester.com for a broader deliverability score. If SPF shows a pass and your score is still low, DKIM or content issues are next on the list.
Getting SPF right is one of the highest-leverage DNS tasks you can do for your domain. It is a single TXT record that, when correct, immediately signals to the world's mail servers that your outbound email is legitimate. Combined with DKIM and DMARC, it forms an authentication stack that dramatically improves inbox placement and protects your brand from being spoofed. There is no good reason to leave it broken.