🍱 Lunchbox Hands

SPF Record Checker & Generator

Check any domain's SPF record: syntax errors, the 10 DNS lookup limit with every include followed, and plain-English meaning of each term. Or generate a correct record.

SPF is a TXT record that says which servers may send mail for your domain. Receivers look it up on every message, and the two ways it quietly breaks are syntax that receivers reject and too many DNS lookups: RFC 7208 allows ten, and every provider you include brings its own. This tool fetches the record from public DNS, follows each include: the way a mail server would, counts the lookups, and explains every term in plain English. The Generate tab builds a clean record from a list of providers; the Validate tab checks text you have not published yet.

SPF alone does not stop spoofing of the visible From address. For that you need DMARC, which builds on SPF and DKIM. If you only want to see the raw TXT records, use the DNS Lookup.

How an SPF record is read

A receiver takes the domain from the envelope sender, fetches its TXT records, and keeps the one that begins with v=spf1. It then walks the terms left to right and stops at the first match. ip4: and ip6: match the connecting server's address directly. a and mx resolve the domain's own address or mail-server records. include: evaluates another domain's record and matches if that record would pass. The qualifier in front of a term (+ pass, - fail, ~ softfail, ? neutral) is the result when it matches; a missing qualifier means pass. Whatever all says at the end is the result for everyone else.

The lookup limit, and why it sneaks up on you

Each include, a, mx, ptr, exists and redirect costs one DNS query, and the included records' own terms count too. Ten is the ceiling (RFC 7208 §4.6.4). A domain that uses Google Workspace, a CRM, a help desk, a newsletter tool and a transactional mail API can hit twelve without anyone noticing, because every setup guide says "just add our include". Over the limit the whole record is a permerror, and messages that used to pass start failing DMARC. The fixes are to remove providers you no longer use, replace an include that only contains fixed addresses with those ip4/ip6 ranges (they are free), or move a sender to its own subdomain with its own record.

Mistakes this checker flags

  • Two records. Two TXT records starting with v=spf1 cancel each other out. Merge them.
  • +all or no all. "+all" authorises the whole internet; a record with no "all" and no redirect is neutral for everyone, which protects nothing.
  • ptr. Deprecated since RFC 7208, slow for receivers, and it still costs lookups.
  • Includes with no record. Including a domain that has no SPF record is a permerror by itself (RFC 7208 §5.2), and it also counts as a "void lookup"; more than two void lookups and receivers may stop evaluating.
  • Terms after all. Never evaluated.
  • redirect= together with all. The redirect is ignored.
  • Records over 255 characters need to be split into several quoted strings; over about 450 bytes they may not fit a UDP reply.

Related tools

Frequently asked questions

What is an SPF record?

A TXT record at your domain that lists which servers are allowed to send email using your domain in the envelope sender (the Return-Path, also called MAIL FROM). It starts with "v=spf1" and ends with a rule for everyone not listed, usually "-all" (fail) or "~all" (softfail). Receiving mail servers look it up for every message and use the result as one input to spam filtering and, through DMARC, to decide whether to reject spoofed mail. It is defined in RFC 7208.

What is the SPF 10 DNS lookup limit?

RFC 7208 §4.6.4 says a receiver may perform at most 10 DNS-querying terms while evaluating your record: every include, a, mx, ptr, exists and redirect counts, across your record and everything it includes. ip4, ip6 and all are free. Go over 10 and the result is "permerror", which most receivers treat as if you had no SPF record at all, so your mail can start failing DMARC. The limit is easy to hit because many providers' includes contain further includes of their own, so one line in your record can cost two or more lookups (include:sendgrid.net costs two, because it includes ab.sendgrid.net). Google Workspace and Microsoft 365 publish flat IP lists and are one lookup each, but a CRM plus a help desk plus a newsletter tool plus a ticketing system can push a domain to 12 or 15. This tool follows every include and counts the total the way a receiver does.

What is the difference between -all and ~all?

"-all" (fail) tells receivers that any server not listed is not authorised, so the message should be treated as forged. "~all" (softfail) says the same thing but with less confidence: mark it suspicious, do not reject it outright. In practice most big receivers treat the two similarly, because the decision to reject usually comes from your DMARC policy rather than the SPF qualifier. The common advice is to publish "~all" while you are still discovering legitimate senders, then switch to "-all". "?all" (neutral) and "+all" (pass everything) provide no protection; "+all" is worse than having no record.

Why does the checker say "multiple SPF records"?

A domain must have exactly one TXT record that begins with "v=spf1". If there are two, for example because a second provider's setup guide told you to "add" a record and you did not merge it into the existing one, RFC 7208 §4.5 makes the result a permerror and receivers ignore both. The fix is to combine them into a single record: keep one "v=spf1" at the start, list every include and IP once, and one "all" rule at the end.

Does SPF stop spoofing on its own?

No. SPF only checks the envelope sender, which the recipient never sees. A forger can put your domain in the visible From header while using their own domain in the envelope, and SPF will pass. Stopping that requires DMARC, which checks that the domain SPF (or DKIM) validated aligns with the From header, and tells receivers what to do when it does not. Set up SPF, then DKIM, then publish a DMARC record; our DMARC checker handles the last step.

Is my record text sent to your server?

The Check tab queries public DNS-over-HTTPS resolvers (Cloudflare, then Google as a fallback) directly from your browser; we do not see the domain or the answers. The Generate and Validate tabs are pure in-browser code and make no network requests at all. We log only that the tool was used, not what you typed.

Get weekly dev tools and tips