Instantly look up and validate any domain's SPF record. Check for errors, count DNS lookups, and get actionable recommendations — free, instant, no account needed.
Enter any domain — e.g. yourdomain.com. We'll look up its live SPF record instantly.
Fix Your SPF — Then Fix Your Inbox Placement with Warmbase
A valid SPF record is only the first step. To consistently land in the primary inbox — not spam — you need to warm up your sending domain, build reputation, and maintain it. Warmbase automates all of it.
An SPF checker is a diagnostic tool that looks up a domain's SPF (Sender Policy Framework) DNS record and analyses it for validity, syntax errors, DNS lookup usage, and deliverability risks. Instead of manually querying DNS and interpreting raw TXT records, an SPF checker does all the heavy lifting — surfacing issues, counting DNS lookups, parsing mechanisms, and providing actionable recommendations.
Our free Warmbase SPF Checker performs a live DNS lookup on any domain you enter, parses the SPF record, validates it against RFC 7208, counts DNS lookups, detects errors and warnings, checks for DMARC and DKIM, and gives you a full deliverability analysis — all in real time, with no signup required.
How SPF Works
Sender Policy Framework (SPF) is an email authentication standard defined in RFC 7208. It allows domain owners to publish — via a DNS TXT record — a list of IP addresses and mail servers that are authorised to send email on their behalf.
When a receiving mail server accepts an incoming message, it checks the SPF record of the domain in the envelope-from (Return-Path) address. It evaluates each mechanism in the record — include:, ip4:, ip6:, mx, a — to determine whether the connecting IP is authorised. If it is, SPF returns pass. If not, it returns fail, softfail, or neutral depending on the all qualifier.
The result influences inbox placement, spam filtering, and DMARC policy enforcement. A missing or broken SPF record is one of the most common causes of email deliverability problems.
How to Check an SPF Record
Using our checker is the fastest way. Simply enter your domain name above and click Check SPF Record. You'll get a full analysis in seconds.
Alternatively, you can check an SPF record manually using the command line:
Linux / macOS:dig TXT yourdomain.com | grep spf
Windows:nslookup -type=TXT yourdomain.com
Look for a TXT record starting with v=spf1. If no such record exists, your domain has no SPF configured. Our checker also checks for DMARC (_dmarc.yourdomain.com) and common DKIM selectors automatically.
SPF Syntax Explained
A valid SPF record always begins with v=spf1 followed by one or more mechanisms and ends with an all qualifier:
Each mechanism has an optional qualifier prefix that defines the result when the mechanism matches:
+ (default) — Pass: the sender is authorised
- — Fail (HardFail): the sender is explicitly rejected
~ — SoftFail: the sender is suspect but not hard-rejected
? — Neutral: no assertion is made
Mechanisms are evaluated left to right. The first match wins. If no mechanism matches, the all mechanism at the end defines the default outcome.
SPF include: Mechanism Explained
The include: mechanism delegates SPF authority to another domain. When an SPF evaluator encounters include:_spf.google.com, it looks up the SPF record at _spf.google.com and evaluates it. If that record matches the connecting IP, SPF passes for the original domain too.
Every include: costs one DNS lookup. And the included domain's SPF record may itself contain further includes, each adding to the total lookup count. This is why the 10-lookup limit is reached faster than you might expect when using multiple ESPs.
Common includes you may see: include:_spf.google.com (Google Workspace), include:spf.protection.outlook.com (Microsoft 365), include:sendgrid.net (SendGrid), include:amazonses.com (Amazon SES).
SPF DNS Lookup Limit Explained
RFC 7208 strictly limits SPF evaluation to 10 DNS lookups per record. Mechanisms that consume lookups include: include:, a, mx, exists:, redirect=, and ptr:. Mechanisms that do not consume lookups include: ip4:, ip6:, and all.
If an SPF record requires more than 10 DNS lookups during evaluation, receiving servers must return permerror — treating the SPF check as failed. Under a DMARC policy of p=reject, this will cause your legitimate email to be rejected.
Our checker counts the DNS lookups used by your top-level SPF record and clearly indicates how close you are to the limit. The colour-coded counter shows green (safe), yellow (approaching), or red (exceeded).
SPF SoftFail (~all) vs HardFail (-all)
The all mechanism is the most important part of your SPF record. It defines what happens when no other mechanism matches:
~all (SoftFail) — The email is accepted but marked as suspicious. DMARC can still quarantine or reject the message based on its own policy. Recommended for most domains, especially while setting up authentication for the first time.
-all (HardFail) — Any mail from an unauthorised IP is explicitly rejected. This provides the strongest protection against spoofing but requires that every legitimate sender is in your record. Use only when you are confident all senders are accounted for.
?all (Neutral) — No enforcement. Equivalent to having no SPF for unlisted senders. Not recommended for production use.
+all (Pass all) — Extremely dangerous. Authorises any server on the internet to send email as your domain. Never use this.
For cold email, ~all is generally the safer starting point. Once you've verified all senders via DMARC reports, move to -all for maximum protection.
Common SPF Mistakes
Multiple SPF records — Only one v=spf1 TXT record is allowed per domain. Two or more causes SPF to fail entirely.
Exceeding 10 DNS lookups — The most common problem for growing email stacks. Each ESP you add likely adds 1–3 lookups.
Using +all — Authorises any server. An open invitation for spoofers.
Missing the all mechanism — Without it, SPF has no defined policy for unmatched senders.
Duplicate include: entries — Wastes DNS lookups without adding any protection.
Adding SPF to a subdomain when you send from the root domain — SPF is evaluated against the envelope-from domain. Make sure the record is on the right domain.
Not updating SPF when changing ESPs — Old includes for services you no longer use consume lookups needlessly.
Relying on SPF alone — SPF breaks on email forwarding. Combine with DKIM and DMARC for reliable authentication.
How to Fix Common SPF Errors
Too Many DNS Lookups
Fix: SPF flattening. Replace include: mechanisms with the raw ip4: CIDR ranges they resolve to. For example, instead of include:sendgrid.net, list the actual SendGrid IP ranges as ip4: entries. This reduces lookups to zero for those entries. Note: IP ranges change, so you must keep flattened records up to date.
Multiple SPF Records
Delete all but one SPF TXT record at your DNS provider. Merge all include: and ip4: entries into that single record.
No SPF Record
Add a TXT record at the root of your domain (@) with value v=spf1 ~all as a starting point, then add include: entries for each sending service.
Missing all Mechanism
Add ~all or -all as the very last token in your SPF record.
SPF Record for Google Workspace
The correct SPF include for Google Workspace is:
v=spf1 include:_spf.google.com ~all
include:_spf.google.com is Google's canonical SPF record and authorises all Google mail servers. Do not use include:google.com — that is incorrect. Google's include internally expands to a small number of additional lookups, so budget accordingly when combining with other services.
Alongside SPF, Google Workspace requires DKIM setup: go to Admin Console → Apps → Google Workspace → Gmail → Authenticate Email and generate a DKIM key. After publishing the DNS record, allow 48 hours for propagation before enabling DKIM signing.
SPF for Cold Email Outreach
Cold email deliverability depends on authentication. Without a valid SPF record, major mailbox providers (Gmail, Outlook, Yahoo) will penalise your messages or route them directly to spam.
For cold email senders:
Use a dedicated sending domain (never your primary business domain) to protect your main brand from reputation damage.
Publish a clean SPF record with only the ESPs you actively use. Avoid the 10-lookup limit.
Use ~all (SoftFail) while warming up your domain. Once SPF, DKIM, and DMARC are all passing, you can tighten to -all.
Set up DKIM — it survives email forwarding where SPF fails, and is critical for DMARC alignment.
Add a DMARC policy starting with p=none to monitor, then tighten to p=quarantine or p=reject.
Warm up your inbox before sending campaigns. A freshly created domain or mailbox with no sending history will be heavily filtered regardless of authentication.
Warmbase automates inbox warming — it simulates real human-like interactions to build your sender reputation before you launch outreach.
SPF Flattening Explained
SPF flattening is the process of replacing DNS-querying mechanisms (include:, a, mx) with their underlying ip4: or ip6: equivalents. Because ip4: and ip6: require zero DNS lookups, flattening reduces your total lookup count — letting you stay under the 10-lookup limit even with many sending services.
Caveat: ESP IP ranges change. If you flatten your SPF record, you must monitor and update the IP ranges regularly — otherwise your SPF may exclude legitimate sending IPs when the ESP updates their infrastructure. Some DNS providers and SPF management tools offer automated flattening that stays current.
SPF vs DKIM vs DMARC
These three standards work together to form a complete email authentication stack. Each addresses a different attack surface:
SPF (Sender Policy Framework) — Validates the envelope-from domain (Return-Path). Checks which mail servers are allowed to send email for a domain. Fails on forwarded email because the connecting IP changes. Published as a DNS TXT record.
DKIM (DomainKeys Identified Mail) — Adds a cryptographic signature to every outgoing message, tied to a specific domain. The signature survives forwarding (as long as the email body isn't modified). Published as a DNS TXT record at selector._domainkey.yourdomain.com.
DMARC (Domain-based Message Authentication, Reporting & Conformance) — Ties SPF and DKIM results to the visible From: header and defines a policy for failures (none, quarantine, reject). Also enables aggregate reporting so you can see who's sending email as your domain. Published as a DNS TXT record at _dmarc.yourdomain.com.
You need all three for robust protection. SPF + DKIM gives you authentication. DMARC gives you enforcement and visibility.
Troubleshooting SPF Issues
SPF passes but mail still goes to spam
SPF passing does not guarantee inbox placement. Check: Is DKIM configured? Is DMARC set up? Is your sending domain warmed up? Are you on any IP blocklists? Is your content triggering spam filters?
SPF keeps failing despite a correct record
Check whether your ESP rewrites the Return-Path to its own domain (e.g. bounces.sendgrid.net). SPF is evaluated against the Return-Path, not the visible From header. If that is the case, the ESP's own domain needs the SPF record — not yours.
permerror in DMARC reports
This almost always means you have exceeded the 10-DNS-lookup limit. Use our checker to count your lookups, then remove unused includes or flatten your record to get under the limit.
Mail fails SPF after adding a new ESP
You added a new sending service but forgot to add its include: to your SPF record. Update the record to include the new provider, then wait for DNS propagation (up to 48 hours).
DNS propagation delays
SPF record changes can take up to 48 hours to propagate globally, though most resolvers see changes within 15–30 minutes. Use our checker to confirm the live record is correct after editing.
Frequently Asked Questions
An SPF checker is a tool that performs a live DNS lookup for a domain's SPF TXT record, validates it for syntax errors, counts DNS lookups, parses all mechanisms, and flags issues that could affect email deliverability. Our free checker also detects DMARC and DKIM records for a full authentication picture.
Common reasons: exceeding 10 DNS lookups, having multiple SPF records on the same domain, missing the all mechanism, a syntax error in the record (like a typo in a domain name), or using +all which is technically valid but extremely dangerous.
RFC 7208 limits SPF evaluation to 10 DNS lookups per record. Mechanisms that count toward the limit include: include:, a, mx, exists:, redirect=, and ptr:. Mechanisms that do not count: ip4:, ip6:, and all.
Receiving mail servers return permerror for your SPF check. Under a DMARC policy of p=quarantine or p=reject, this causes legitimate email to be quarantined or rejected. To fix, remove unused includes or flatten your SPF record by replacing include: mechanisms with direct ip4: addresses, which consume zero lookups.
~all is the SoftFail qualifier. It tells receiving servers that mail from an IP not listed in your SPF record is suspicious but should still be delivered (marked, not rejected). It is the recommended starting point for most domains. Once all senders are verified, you can tighten to -all.
-all (HardFail) is stricter — it explicitly rejects mail from unauthorised IPs. It offers better anti-spoofing protection but is less forgiving if you accidentally miss a sender. Use ~all first, monitor DMARC reports, confirm all senders are in the record, then switch to -all for maximum protection.
SPF is a baseline authentication requirement. Major providers including Gmail, Outlook, and Yahoo check SPF before deciding where to route your mail. Since Google and Yahoo's 2024 bulk sender requirements, SPF (together with DKIM and DMARC) is effectively mandatory for anyone sending at scale.
No. RFC 7208 explicitly states that only one SPF TXT record is permitted per domain. If multiple records starting with v=spf1 are found, SPF evaluation returns permerror and fails entirely. Merge all your mechanisms into a single record and delete the duplicates.
Yes, significantly. A missing or broken SPF record is one of the fastest ways to end up in the spam folder. Cold email requires correct SPF, DKIM, and DMARC configuration — plus inbox warming to build sender reputation. Warmbase automates the warming process so your emails consistently reach the primary inbox.
No — SPF breaks on forwarded email because the connecting IP changes to the forwarder's IP, which is not in your SPF record. This is a fundamental SPF limitation. DKIM does not have this problem (it signs the message, not the connection), which is why combining SPF with DKIM and DMARC is essential for robust authentication.
SPF flattening resolves all include: mechanisms to their underlying IP ranges and rewrites them as ip4: entries. Since ip4: consumes zero DNS lookups, flattening lets you authorise many senders without hitting the 10-lookup limit. The trade-off: ESP IP ranges change, so flattened records need regular updates.
Ready to Reach the Inbox?
You have your SPF record — now finish the setup. Warmbase automatically warms up your sending inboxes so every cold email, outreach sequence, and transactional message lands in the inbox, not the spam folder.
