Every cold email that lands in spam instead of the inbox has a reason. Missing or broken SPF records are responsible for more inbox placement failures than almost any other single cause — and most senders do not know their SPF record is broken until they check. Setting up SPF takes under 10 minutes. Not having it costs you deliverability every day it is missing.
💡 TL;DR
An SPF record is a DNS TXT record that tells receiving mail servers which IPs are authorised to send email from your domain. Without it, your emails fail authentication and get sorted to spam or rejected — regardless of how good your copy is. For Google Workspace: v=spf1 include:_spf.google.com ~all. For Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all. One SPF record per domain maximum — multiple records cancel each other out. Verify with MXToolbox before sending. Litemail pre-configures SPF on every inbox so you never have to do this setup manually.
What an SPF Record Actually Does — No Jargon
SPF stands for Sender Policy Framework. It is a DNS record that answers one specific question: "Is this IP address allowed to send email on behalf of this domain?"
When you send an email, the receiving server checks your domain's DNS records for an SPF record. If it finds one that includes the IP address your email came from, it passes. If it does not find one — or if the IP is not listed — it either marks the email as suspicious or rejects it entirely, depending on how the receiving server is configured.
Without SPF: receiving servers have no way to verify your email is legitimate. Many will sort it to spam automatically. Some will reject it before delivery. In practice, a missing SPF record costs 10 to 20 percentage points of inbox placement — every day, on every email you send from that domain.
SPF Record Syntax — What Each Part Means
An SPF record looks technical. But once you understand what each component does, it is straightforward to set up correctly — and easy to spot when it is wrong.
Component | What It Does | Example |
|---|---|---|
v=spf1 | Declares this is an SPF record — always first | v=spf1 |
include: | Authorises IPs owned by a third-party service | include:_spf.google.com |
ip4: | Authorises a specific IPv4 address or range | ip4:123.45.67.89 |
~all | Soft fail — unauthorised IPs are marked suspicious but not rejected | ~all |
-all | Hard fail — unauthorised IPs are rejected | -all |
?all | Neutral — no policy on unauthorised IPs (not recommended) | ?all |
Use ~all (soft fail) when setting up SPF for the first time — it gives you visibility into authentication failures without risking legitimate email being rejected. Move to -all (hard fail) after 30 days of clean authentication data and once you are confident all legitimate sending sources are listed.
SPF Record Setup by Email Platform — Exact DNS Records
Here are the exact SPF records for the most common cold email sending platforms. Add these as TXT records in your domain registrar's DNS management panel. One record per domain — do not create multiple SPF records for the same domain.
📋
Google Workspace
TXT record: v=spf1 include:_spf.google.com ~all. Add at the root domain (@). This covers all Google Workspace sending IPs including Gmail's outbound infrastructure. If you also send from other services (CRM, marketing tool), add their include: entries before the ~all: v=spf1 include:_spf.google.com include:other-service.com ~all.
📋
Microsoft 365
TXT record: v=spf1 include:spf.protection.outlook.com ~all. Same rules apply — add at root domain, only one SPF record. Microsoft 365's SPF record covers Exchange Online sending IPs. If you are also sending from Dynamics or other Microsoft services, Microsoft's own documentation lists the additional include: entries needed.
📋
Custom SMTP (other providers)
If you are connecting a cold email sending tool via SMTP, check the tool's documentation for their SPF include: entry. Most major providers (SendGrid, Mailgun, Postmark) have a dedicated SPF include: subdomain. Add it alongside your primary email platform's include: entry in the same SPF record.
The 3 Most Common SPF Mistakes That Break Cold Email Deliverability
These mistakes are responsible for a disproportionate share of cold email deliverability problems. Check every new sending domain for all three before the first send.
❌
Mistake 1: Multiple SPF records on the same domain
This is the most common mistake and one of the most damaging. DNS only evaluates one SPF record per domain. If there are two SPF TXT records — for example, from two different services you set up at different times — the result is unpredictable. Some servers will fail both; some will pick one arbitrarily. The fix: merge all SPF entries into a single TXT record. v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all is a valid single record.
❌
Mistake 2: SPF record with too many DNS lookups
Each include: statement in an SPF record triggers a DNS lookup. The SPF standard limits total lookups to 10. Go over 10 and the SPF record returns a PermerError — which most servers treat as a failure. Check your lookup count at kitterman.com/spf/validate.html before finalising any SPF record with multiple include: entries.
❌
Mistake 3: SPF without DKIM and DMARC
SPF alone is not enough. Without DKIM, your emails are not cryptographically signed — receiving servers cannot confirm the email content has not been modified in transit. Without DMARC, there is no policy for what to do when SPF or DKIM fails. All three work together. SPF passing while DKIM or DMARC is missing still results in email being sorted to spam by many receiving systems.
How to Verify Your SPF Record Is Working — Before Sending a Single Email
Setting up the record is step one. Verifying it is working is step two — and most people skip it. Here is the 10-minute verification process.
Go to MXToolbox → SPF Record Lookup. Enter your sending domain. Confirm one SPF record exists, it passes validation, and all include: entries resolve without errors.
Check lookup count. MXToolbox's result shows DNS lookup count. Keep it under 10. If it is over 10, consolidate include: entries using SPF flattening tools like AutoSPF.
Send a test email to a Gmail address. Open the email. Click the three dots in the top right. Select "Show original." In the Authentication-Results header, look for: spf=pass. If it shows spf=fail or spf=softfail, the record is misconfigured.
Check that DKIM and DMARC are also passing. Same header. You want: dkim=pass and dmarc=pass alongside spf=pass. Any failure is a deliverability problem that needs fixing before launching a campaign.
[INTERNAL LINK: DKIM setup guide for cold email → /blog/dkim-setup-cold-email]
SPF, Pre-Warmed Inboxes, and Cold Email — How They Fit Together
SPF is necessary but not sufficient for cold email deliverability. Think of it as one layer in a three-layer authentication stack: SPF verifies the sending IP, DKIM signs the message, and DMARC sets the policy for failures. All three need to be in place.
The good news: if you are using Litemail pre-warmed inboxes, SPF, DKIM, and DMARC are pre-configured on every inbox before delivery. You do not go through the manual DNS setup and propagation wait. Postmaster-verified reputation within 48 hours means authentication is already passing when the inbox is handed over — not something you need to set up and debug.
For teams managing their own domain setup, the manual process adds 2 to 3 days per domain batch due to DNS propagation time. At 10 clients with 3 domains each, that is 30 domains × 2 to 3 days = 60 to 90 days of staggered setup time. Pre-configured authentication at the inbox level collapses that to 48 hours per batch regardless of domain count.
The Bottom Line
An SPF record is a DNS TXT record that tells receiving servers which IPs are authorised to send from your domain. Missing SPF costs 10 to 20 percentage points of inbox placement — every day, on every email from that domain.
For Google Workspace: v=spf1 include:_spf.google.com ~all. For Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all. One record per domain only.
Multiple SPF records on one domain are one of the most common cold email deliverability mistakes — they result in unpredictable authentication failures.
SPF alone is not enough. DKIM and DMARC must also be configured. All three need to show pass in email headers before launching any campaign.
Verify using MXToolbox SPF Lookup and a Gmail test email before the first send. Fixing a broken SPF record takes 5 minutes; finding it after 2 weeks of underperformance is far more expensive.
Litemail pre-configures SPF, DKIM, and DMARC on every inbox — eliminating the 2 to 3 day per-domain manual setup and DNS propagation wait for teams managing multiple sending domains.
Frequently Asked Questions
What is an SPF record in email?
An SPF record is a DNS TXT record that specifies which IP addresses and mail servers are authorised to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to verify the sending IP is on the authorised list. A missing or misconfigured SPF record causes authentication failures that send email to spam.
How do I set up an SPF record for cold email?
Go to your domain registrar's DNS management panel. Add a TXT record at the root domain (@) with your email platform's SPF entry: v=spf1 include:_spf.google.com ~all for Google Workspace, or v=spf1 include:spf.protection.outlook.com ~all for Microsoft 365. Allow 24 to 48 hours for DNS propagation, then verify at MXToolbox before sending.
Can I have two SPF records on one domain?
No. Only one SPF TXT record per domain is valid. Multiple SPF records cause authentication failures because receiving servers cannot resolve which record to apply. If you need to include multiple email services, merge them into one record: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all.
Is SPF enough for cold email deliverability?
No. SPF is one layer of a three-layer authentication requirement. DKIM (message signing) and DMARC (failure policy) must also be configured. As of 2024, Google and Microsoft both enforce DMARC for bulk senders. Missing DKIM or DMARC results in spam routing even when SPF is passing. All three need to show pass in email headers before launching a cold email campaign.
How do I check if my SPF record is working?
Go to MXToolbox.com and use the SPF Record Lookup tool. Enter your domain and confirm one valid record exists with no errors. Send a test email to a Gmail address and view the original message headers — look for spf=pass in the Authentication-Results section. Any spf=fail or spf=softfail means the record needs fixing.
What does the ~all vs -all difference mean in an SPF record?
~all (soft fail) means emails from unauthorised IPs are marked as suspicious but usually still delivered. -all (hard fail) means emails from unauthorised IPs are rejected outright. Start with ~all when setting up SPF for the first time — it lets you catch any legitimate sending sources you missed without blocking email. Switch to -all after 30 days of clean authentication data.
