Free SPF Record Checker

What is SPF and how do receivers use it?

SPF — Sender Policy Framework, defined in RFC 7208 — is a plain TXT record published on your domain that answers one question: which servers are allowed to send email as this domain? When your message arrives at Gmail or Outlook, the receiving server takes the IP address that connected to it, looks up the SPF record of the envelope sender's domain, and checks whether that IP is authorized. If it is, SPF passes; if not, the record's default policy (the all mechanism) tells the receiver how suspicious to be.

Since 2024, Gmail and Yahoo have required authentication from bulk senders outright — mail without SPF or DKIM increasingly doesn't get a spam-folder consolation prize, it gets rejected. A broken SPF record is worse than none in one specific way: a record that receivers can't evaluate (a permerror) makes your domain look misconfigured on every message you send.

How to read an SPF record

An SPF record is a single line that starts with the version tag v=spf1, followed by mechanisms read left to right: ip4: and ip6: authorize explicit addresses or ranges, a and mx authorize the hosts behind the domain's A or MX records, include: pulls in another domain's entire SPF record (this is how you authorize Google Workspace, SendGrid, or any other sending service), and exists: runs a conditional test. ptr also exists, but RFC 7208 deprecates it — it's slow, unreliable, and the SPF check flags it.

Each mechanism can carry a qualifier: + pass (the default), - fail, ~ softfail, ? neutral. In practice qualifiers matter on exactly one mechanism — the all that ends the record and catches every server not matched above it. -all says reject unauthorized mail, ~all says accept but flag it, ?all says nothing at all, and +all — which real records in the wild actually contain — authorizes the entire internet to send as you. Two modifiers round out the syntax: redirect= hands the whole evaluation to another domain's record, and exp= supplies a custom failure message.

The 10-DNS-lookup limit

Here's the rule that quietly breaks more SPF records than any syntax error: receivers will perform at most 10 DNS lookups while evaluating a record. include:, a, mx, ptr, exists: and redirect= each consume one; ip4:, ip6: and all are free. Cross the limit and the result is permerror — your SPF stops working entirely, on every message.

Includes are the killer because they nest. One include: costs a lookup, and then every lookup-consuming mechanism inside the included record counts against your budget too. A single vendor include can quietly cost three or four lookups. Sign up for a CRM, a helpdesk, a newsletter tool and a transactional provider, and a record that looks like four harmless includes can already be at nine or ten. The SPF check resolves the whole tree recursively and shows you the true count, so you know how much headroom you actually have before the next tool you adopt pushes you over.

Common SPF failures and how to fix them

• Multiple SPF records. Two or more v=spf1 TXT records on one domain is an automatic permerror — receivers ignore all of them. It usually happens when a vendor's setup guide says "add this TXT record" and it gets added next to the existing one. Fix: merge every mechanism into a single record.
• +all or a missing all. +all authorizes anyone on the internet to send as your domain; a record with no all and no redirect= never states a policy, so unknown senders default to neutral. Fix: end the record with ~all or -all.
• Too many lookups. Over 10 and SPF permerrors. Fix: drop includes for tools you no longer use, replace a and mx with explicit ip4:/ip6: ranges, and flatten heavyweight includes into raw IPs (with a process for keeping them current — vendor IPs change).
• Stale vendor includes. Every include is a standing grant of permission to send as you. Audit the record when you churn off a provider — an include for a tool you abandoned two years ago is pure attack surface and wasted lookup budget.

SPF vs DKIM vs DMARC

The three standards answer different questions and only work as a set. SPF authorizes sending servers. DKIM puts a cryptographic signature on each message, proving it came from your domain and wasn't altered in transit. DMARC sits on top and supplies the two things the others lack: alignment — the domain that passed SPF or DKIM must match the From address your recipients actually see, which is what finally stops display-name spoofing — and a policy telling receivers what to do when both checks fail, plus reports so you can see who's sending as you.

A useful mental model: SPF and DKIM are two independent proofs of identity, and DMARC is the enforcement layer that requires at least one proof to align. That's also why forwarding doesn't doom you — forwarding tends to break SPF, but DKIM usually survives, and DMARC only needs one. Check all three: this page for SPF, the DKIM checker for signatures, and the DMARC checker for policy and alignment. And keep the honest caveat in mind: a perfect SPF record proves who you are, not that your mail deserves the inbox — that's a deliverability problem, and it starts with the quality of the list you send to.