Deliverability Score

Free tool · No signup

Free SPF record checker

Validate your SPF record syntax, count DNS lookups, and find issues that are sending your email to spam.

Results in 5 seconds · 100% free

Primer

What is SPF?

SPF stands for Sender Policy Framework. It's the first of three email authentication standards, published as a single DNS TXT record at the root of your sending domain. SPF tells every receiving mail server — Gmail, Outlook, Yahoo, Apple Mail and the rest — which IP addresses are authorized to send mail on your behalf. When an email arrives, the receiver looks up your SPF record, checks whether the sending IP matches, and uses that result to decide whether to accept, quarantine or reject the message.

Without SPF — or with broken SPF — two bad things happen. Legitimate mail from your own ESP starts landing in spam because receivers can't verify it actually came from you. And spoofed mail from impersonators slides through, because there's no record telling receivers that the address you@yourbrand.com is supposed to come from a specific set of servers. The combination is brutal: your customers don't see your real emails, and attackers' fake ones get delivered.

SPF is one of three core email authentication standards (alongside DKIM and DMARC) that Gmail and Yahoo now require as of February 2024 for any sender pushing more than 5,000 messages per day. Microsoft, Apple and the other major mailbox providers follow the same playbook. Domains without all three in place are routinely throttled and increasingly filtered to junk regardless of content quality.

An SPF record is a single TXT record at the apex of your domain, beginning with v=spf1, listing every authorized sender via include: (delegating to another domain's SPF), ip4: (authorizing a specific IPv4 address), or a: and mx: (authorizing the A and MX records of a host), and closing with a fallback policy — typically ~all for soft fail or -all for hard fail. The whole thing lives in one line, and there can only be one SPF record per domain.

Anatomy

How to read your SPF record

Every SPF record packs a lot into a single line. Here's what each part of a typical record does.

Example record

v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.168.1.1 ~all
v=spf1

Version tag. Every SPF record must start with v=spf1, with no whitespace before it.

include:_spf.google.com

Delegates SPF to Google. Whatever IPs Google authorizes for Workspace, this domain inherits. Each include: counts as one of your 10 allowed DNS lookups.

include:sendgrid.net

Delegates SPF to SendGrid. Same mechanism — pulls in SendGrid's authorized sending IPs. Stack one include: per ESP.

ip4:192.168.1.1

Authorizes a specific IPv4 address directly. Use this for self-hosted SMTP or anything not behind an ESP. ip4: does not consume a DNS lookup.

~all

Policy fallback for everything not listed above. ~all is 'softfail' (typically delivered to spam). Use -all once you're sure every legitimate sender is included.

Common pitfalls

Common SPF mistakes

Too many DNS lookups (over 10)

SPF has a hard 10-lookup limit, and each include: counts toward it — including lookups inside the records you include. Going over causes a permerror and your SPF effectively fails for every receiver.

Multiple SPF records

You can only have one v=spf1 TXT record per domain. Having two — even by accident, usually from an old ESP setup that was never cleaned up — invalidates both and SPF returns permerror.

Using +all

+all tells receivers that any server is authorized to send from your domain, which defeats the entire purpose of SPF and makes your domain trivially spoofable. Always use ~all (soft fail) or -all (hard fail) instead.

Forgetting to include a new ESP

The most common silent failure: someone connects Klaviyo, Mailchimp or SendGrid to your sending stack without updating SPF, so every send from that platform fails authentication. Audit your SPF every time you add or remove a sender.

Trailing whitespace or smart quotes

Pasting an SPF record into your DNS provider's UI sometimes adds invisible whitespace or curly quotes that break parsing silently. Always copy from a plain text source and test the record with a checker after publishing.

The full picture

Want the full picture?

SPF is one of six checks in our complete deliverability audit. See your SPF, DKIM, DMARC, BIMI, blacklists and tracking domain all at once.

FAQ

Frequently asked questions

What's the difference between SPF, DKIM, and DMARC?
SPF tells receivers which IP addresses are allowed to send mail for your domain. DKIM cryptographically signs each message so receivers can verify it actually came from your domain unchanged. DMARC stitches the two together — it tells receivers what to do when SPF or DKIM fail, and provides a feedback channel via aggregate reports. You need all three for modern deliverability; Gmail and Yahoo now require them for bulk senders.
How do I add an SPF record to my domain?
Publish a single TXT record at the apex of your domain (not a subdomain) starting with v=spf1, listing every service that sends on your behalf via include: directives, and ending with ~all or -all. In your DNS provider (Cloudflare, Route 53, Namecheap, GoDaddy), set the host to @ or your domain name. SPF propagates in minutes to hours depending on your TTL.
What does ~all vs -all mean in SPF?
~all is 'soft fail' — receivers treat mail from unauthorized sources as suspicious but typically still deliver it, often to spam. -all is 'hard fail' — receivers can outright reject mail from unauthorized senders. Use ~all while you're still validating your sending sources, then move to -all once you're confident every legitimate sender is included.
Why does my SPF record have too many DNS lookups?
SPF has a hard 10-lookup limit per RFC 7208, and most domains hit it by chaining include: directives. Each include:, a:, mx:, exists:, redirect=, and ptr counts, plus every lookup-incurring mechanism inside each included record counts too. The fix is usually to remove unused includes (legacy ESPs you no longer use) or to flatten the record using a service like EasyDMARC or PowerDMARC.
Can I have more than one SPF record?
No. RFC 7208 requires exactly one v=spf1 TXT record per domain. Having two — even if both look correct — causes a permerror, and receivers treat your SPF as broken. Merge multiple records into a single TXT record with all the include: directives combined.
Does SPF stop email spoofing on its own?
No. SPF alone doesn't prevent spoofing. SPF only validates the envelope sender (the MAIL FROM address), which most users never see — the From: header in the inbox can still be spoofed. You need DMARC layered on top to enforce alignment between the SPF-authenticated domain and the visible From: domain.
How often should I check my SPF record?
Check it any time you add or remove a sending service, and re-audit at least quarterly. The most common silent failure is signing up for a new ESP, transactional service or CRM without updating SPF, which means those sends immediately fail authentication — often without anyone noticing until deliverability drops.
What happens if my SPF record fails?
A 'softfail' (~all) typically lands mail in spam; a 'hardfail' (-all) can cause outright rejection. A 'permerror' — usually from too many DNS lookups or syntax issues — makes the entire SPF check unusable, which weakens DMARC alignment and hurts inbox placement. Receivers also feed SPF results into their internal reputation systems, so persistent failures damage your sender score over time.