Free SPF Raw Checker: Validate Your Syntax Before You Publish

It validates the syntax of an SPF record you paste in, before that record ever reaches your DNS. Enter your domain and the raw record string, press Validate Syntax, and the tool parses it exactly the way a receiving mail server would: it confirms the v=spf1 prefix is present and correctly positioned, verifies every mechanism and qualifier is well-formed, counts the DNS lookups your record will trigger against the limit of 10, and checks the string against SPF length limits. Catching a malformed record here costs you nothing, whereas catching it after publication can mean hours of failed authentication.

The SPF Checker looks up the record currently live on your domain, while the Raw Checker validates a record you supply yourself. Use the Checker when you want to audit what's already published and diagnose why authentication is failing right now. Use the Raw Checker when you've written or edited a record and want to confirm it's valid before you touch DNS — for example after adding a new sending platform, merging two records into one, or flattening includes to get back under the lookup limit. In a normal workflow you'd validate here first, publish, then confirm with the Checker.

Because several SPF mechanisms only have meaning relative to a specific domain, so the syntax can't be fully validated without one. The bare a and mx mechanisms resolve against the domain the record belongs to, SPF macros such as %{d} expand using it, and an accurate DNS lookup count depends on resolving the includes that domain's record actually points to. Supplying the domain lets the tool evaluate your record the way a real receiving server would rather than checking it in the abstract, which is the difference between confirming a record is well-formed and confirming it will work.

It means your record is structurally valid and will parse without error, which is necessary but not sufficient. A syntactically perfect record still fails to protect you if it omits a platform that sends on your behalf, authorizes services you no longer use, or ends in ?all or +all and effectively permits anyone to send as your domain. SPF also can't stop someone spoofing your brand in the visible "From" field, since it validates the envelope sender instead — so treat a clean syntax check as step one, then confirm your sender list is complete and pair SPF with DKIM and DMARC.

All the structural problems that cause a permerror and silently break authentication. That includes a missing or misplaced v=spf1 prefix, invalid or misspelled mechanisms, senders added without their include: prefix, malformed IP addresses and CIDR ranges, more than one "all" mechanism, mechanisms placed after all where they'll be ignored, redirect combined with an all mechanism, deprecated ptr usage, records exceeding the 255-character single-string limit, and a total DNS lookup count above 10. What it can't catch is a valid include value pointing at the wrong provider — the syntax is fine, so only you can verify the sender list is right.

No. The Raw Checker is entirely read-only: it parses the string you paste and performs DNS lookups to count and expand your includes, but it never writes to your DNS or modifies your published record in any way. Nothing changes for your domain until you manually add or update the TXT record in your DNS provider's control panel, which means you can test as many variations as you like — different include sets, hardfail versus softfail, flattened versus nested — without any risk to mail that's currently sending.