Verify SPF record syntax, count DNS lookups, and identify authorization gaps. Catch errors before emails fail authentication.
An SPF (Sender Policy Framework) record is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks your SPF record to verify the sending server is legitimate.
Think of an SPF record as a guest list for your domain's email. It tells the rest of the internet: “These specific servers are allowed to send mail as us. Anything else claiming to be from our domain is probably fake.”
Without an SPF record, any server in the world can send email pretending to be from your domain. Phishing attacks, spam, and spoofing all become trivially easy. With an SPF record in place, receiving mail servers can check incoming messages against your approved list and flag or reject anything that doesn't match.
SPF records are stored as TXT records in your domain's DNS settings. You manage them wherever you manage your domain's DNS — your domain registrar (GoDaddy, Namecheap, Cloudflare, etc.) or your hosting provider's DNS panel.
Every domain can have only one SPF record. It's a single line of text that starts with v=spf1 and contains a list of approved sending sources. If you use our SPF checker above, you can see exactly what your domain's SPF record looks like right now.
SPF authentication happens behind the scenes every time someone sends an email from your domain. Here's the step-by-step process:
Someone (or some system) sends an email with your domain in the "from" address. This could be you sending from Gmail, your marketing platform sending a campaign, or your CRM firing off an automated follow-up.
When the email arrives at the recipient's mail server (Gmail, Outlook, Yahoo, etc.), the server looks at where the email actually came from -- the IP address of the server that transmitted it.
The mail server performs a DNS lookup on your domain, pulling the TXT record that starts with v=spf1. This is the SPF lookup -- the exact thing our SPF record checker does for you above.
The receiving server compares the sending IP against every authorized source listed in your SPF record. Does the IP belong to Google's mail servers? Is it one of SendGrid's IPs?
Based on the comparison, the SPF check produces a Pass (authorized), Fail (not authorized, reject), SoftFail (not authorized, accept with suspicion), or Neutral (no claim).
When an email fails its SPF check, the outcome depends on your SPF record's enforcement level:
Even a soft fail can tank your deliverability over time if it keeps happening. Consistent SPF failures tell receiving servers that your domain's email hygiene is poor.
SPF records look cryptic at first glance, but they follow a simple structure. Every SPF record is a single string of text made up of mechanisms and qualifiers.
v=spf1Every SPF record must start with v=spf1. This tells the receiving server that this TXT record is an SPF record. There's no v=spf2 — version 1 is the only version.
ip4: and ip6:These let you authorize specific IP addresses or IP ranges to send email for your domain.
ip4:192.168.1.1 — authorizes a single IPv4 address
ip4:192.168.1.0/24 — authorizes a range of 256 IPv4 addresses
ip6:2001:db8::1 — authorizes a single IPv6 address
include:The most common mechanism. It tells the receiving server: “Also check this other domain's SPF record for authorized IPs.” For example, include:_spf.google.com means any server that Google's SPF record authorizes is also authorized for your domain.
Each include: triggers an additional DNS lookup, which matters because of the 10-lookup limit.
-all vs ~all vs ?all-all (hard fail): “Reject anything not on my list.” Strictest setting.~all (soft fail): “Flag anything not on my list, but don't reject it.” Most common setting.?all (neutral): “I make no claim about unlisted sources.” Rarely useful.+all (pass all): “Authorize everyone.” Security disaster — fix immediately.Google Workspace only:
v=spf1 include:_spf.google.com ~allGoogle Workspace + SendGrid:
v=spf1 include:_spf.google.com include:sendgrid.net ~allMultiple providers with a dedicated IP:
v=spf1 ip4:203.0.113.50 include:_spf.google.com include:sendgrid.net include:mailgun.org ~allThis is where most SPF problems come from, and it's the number one issue our SPF checker flags for users. RFC 7208 imposes a hard limit of 10 DNS lookups per SPF evaluation to protect mail infrastructure from denial-of-service attacks.
This is the trap that catches most people. For example, include:_spf.google.com is one lookup, but Google's SPF record itself includes three more records — that's 4 lookups consumed just for Google Workspace. Add Microsoft 365, SendGrid, and HubSpot, and you've blown past 10.
After running a domain through our SPF record checker, here's how to interpret what you see.
The sending server is authorized by the SPF record. This is the result you want.
The sending server is explicitly not authorized, and the SPF record's hard fail policy says to reject the email.
The sending server is not authorized, but the soft fail policy says to accept with suspicion. Often lands in spam.
The SPF record makes no assertion about whether the sending server is authorized. Rarely what you want.
Something is wrong with your SPF record's syntax -- too many lookups, syntax error, multiple SPF records, or circular include reference. SPF authentication is completely broken.
A temporary DNS failure prevented the SPF check from completing. Usually a DNS server hiccup.
1-7
Safe
8-9
Close
10
At Limit
11+
Invalid
These are the issues we see most often when running SPF checks. If our SPF record checker flagged something for your domain, here's what to do about it.
Your domain has no SPF record at all. Any server can claim to send email as your domain with zero resistance.
Fix: Create an SPF record. If you only use Google Workspace:
v=spf1 include:_spf.google.com ~allYour SPF record ends with +all, which means “authorize every server on the internet to send email as my domain.” This is a massive security hole.
Fix: Change +all to ~all or -all immediately. There is no legitimate reason to use +all.
Your domain has more than one TXT record starting with v=spf1. The SPF specification says you can only have one — having multiple causes a PermError.
Fix: Merge all your SPF records into a single record. Combine the mechanisms from both records into one line.
You're sending email through a service that isn't listed in your SPF record. Those emails will fail SPF checks.
Fix: Add your provider's SPF include directive. Common ones:
Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailgun: include:mailgun.org
Amazon SES: include:amazonses.com
HubSpot: include:spf.hubspot.com
SPF is one piece of a three-part email authentication system. Each part does something different, and you need all three working together for proper email security and deliverability.
Who Is Allowed to Send
Verifies that the sending server is authorized to send email for your domain. Weakness: breaks when emails are forwarded.
Message Integrity
Adds a cryptographic signature to verify the email hasn't been tampered with. Survives forwarding because the signature is embedded in the email.
The Policy Layer
Ties SPF and DKIM together with alignment checks and tells receiving servers what to do when authentication fails.
If you only have SPF but no DKIM or DMARC, you're running with one-third of the authentication stack. Your sender reputation and deliverability will reflect that. Check your DMARC configuration with our free DMARC checker.
An SPF record is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. It helps prevent email spoofing by giving receiving servers a way to verify that incoming email actually came from a server you approved.
Enter your domain in the SPF checker at the top of this page. It will pull your SPF record from DNS, validate the syntax, count your DNS lookups, and show you every authorized sending source. You can also check manually using dig or nslookup in a terminal.
A softfail (~all) means the sending server isn't listed in your SPF record, but your policy says to accept the email anyway while treating it with suspicion. In practice, softfailed emails often land in spam. Most domains use ~all as a safe default.
SPF records are limited to 10 DNS lookups per RFC 7208. This includes every include:, a, mx, redirect=, and exists: mechanism, as well as any nested lookups inside included records. Exceeding 10 lookups makes your entire SPF record invalid.
Yes. While email will technically work without an SPF record, your messages are far more likely to land in spam or be rejected. Every major email provider (Gmail, Outlook, Yahoo) checks SPF as part of their spam filtering. Google and Yahoo now require SPF authentication for bulk senders.
No. The SPF specification requires exactly one SPF TXT record per domain. If you have multiple records starting with v=spf1, receiving servers will return a PermError and SPF authentication fails entirely. Merge all your authorized sources into a single record.
SPF alignment means the domain in the email's Return-Path (envelope sender) matches the domain in the visible "From" header. DMARC requires either SPF or DKIM to be aligned. Without alignment, even a passing SPF check won't satisfy DMARC.
DNS changes typically propagate within 1-4 hours, but full global propagation can take up to 48 hours depending on TTL settings and DNS caching. If you've just updated your SPF record and our checker still shows the old one, wait a few hours and try again.
Your SPF record is just one piece of your email authentication setup. Make sure everything else is dialed in too:
ScaledMail configures SPF, DKIM, and DMARC correctly for every inbox from day one. No DNS headaches, no authentication gaps.
Get Started with ScaledMail