Free tool · Deliverability SPF Record Checker
Validate any domain's SPF record instantly. We catch the silent killers (too many DNS lookups, duplicate records, and weak fail policies) that quietly route your outbound into the spam folder.
How to read your SPF results
SPF tells inbox providers which servers are allowed to send mail for your domain. It looks simple, a single line of DNS, but a few specific mistakes cause the majority of deliverability problems. Here's what our checker looks for and why each one matters.
One record, exactly
A domain may publish only one SPF record. If you have two (a common result of adding a new email tool without merging), receivers return a permanent error and ignore SPF altogether. Everything must live in a single v=spf1 record.
The 10-lookup limit
Each include, a, mx, exists, and redirect mechanism triggers a DNS lookup, and you're capped at 10. Stacking tools (your CRM, your email platform, your help desk, your invoicing software) blows past it fast. When you do, SPF fails for every message. We count your lookups so you know exactly how much headroom is left.
A meaningful "all" mechanism
The record should end in -all or ~all. The first hard-fails unauthorized senders; the second soft-fails them. Avoid ?all (no protection) and never use +all, which lets anyone spoof you.
SPF is one of three pillars
SPF, DKIM, and DMARC work together. SPF authorizes servers, DKIM signs messages, and DMARC tells receivers what to do when a check fails, and gives you reporting. If you're sending outbound at volume, all three need to be correct on every domain you send from. Check your DKIM record and DMARC policy next, or run the full deliverability test for a single combined score.
Setting this up correctly across a fleet of sending domains, and keeping it healthy, is exactly what we do. See how we handle cold email infrastructure for clients, or read the full SPF, DKIM & DMARC guide for cold email.
Frequently asked questions
What is an SPF record?
An SPF (Sender Policy Framework) record is a DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain. When a receiving server gets your message, it checks the sending IP against this list. If the IP isn't authorized, the mail can be marked as spam or rejected, which is why a correct SPF record is foundational to deliverability.
How do I check my SPF record?
Enter your domain above and we'll look up the TXT records on your root domain, find the one starting with "v=spf1", and validate it. We flag the most common problems: more than one SPF record, exceeding the 10 DNS-lookup limit, a missing or weak "all" mechanism, and the deprecated "ptr" mechanism.
What is the SPF 10 DNS-lookup limit?
RFC 7208 limits an SPF record to 10 DNS-querying mechanisms (include, a, mx, ptr, exists, redirect). Go over it and receivers return a "permerror". Your SPF is ignored entirely, even if everything else is correct. Adding too many email tools is the usual cause. The fix is to flatten includes or remove senders you no longer use.
Should SPF end with ~all or -all?
"-all" (hardfail) tells receivers to reject any mail from a server not on your list, the strictest setting. "~all" (softfail) tells them to accept but mark it suspicious. Start with "~all" while you confirm every legitimate sender is included, then tighten to "-all". Never use "+all", which authorizes the entire internet to send as your domain.
Why does my cold email go to spam even with SPF set up?
SPF is only one of three pillars. You also need DKIM (a cryptographic signature) and DMARC (a policy tying them together), plus a warmed-up domain and clean sending reputation. A valid SPF record is necessary but not sufficient. Run the full deliverability test to see the complete picture.
Keep your outbound landing.
SPF Record Generator
v=spf1 include:_spf.google.com include:hubspotemail.net ~all
Pick your email platforms, add any server IPs, and copy a TXT record already checked against the 10-lookup limit.
DKIM Checker
Look up and validate your DKIM record. Don't know your selector? It tries the common ones and verifies your public key.
DMARC Checker
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
"p=none" only monitors. It doesn't protect against spoofing. It's the right place to start; once your reports look clean, move to "quarantine" then "reject".
Read your DMARC policy in plain English, see whether you're protected or just monitoring, and confirm reporting is on.
Want us to build your outbound system?
Skip the DIY. We'll orchestrate your entire outbound operation, on infrastructure registered in your name from day one.
Book your free ICP review →