Validate your SPF record syntax in seconds. Detect malformed mechanisms, invalid qualifiers, incorrect ordering, and formatting errors that silently break your email authentication.
An SPF record follows a strict syntax defined by RFC 7208. Every valid SPF record is a single DNS TXT record that begins with the version tag v=spf1, followed by one or more mechanisms and modifiers, and typically ends with an all mechanism. Understanding this syntax is essential because even a single character out of place can cause your entire email authentication policy to fail silently.
The building blocks of an SPF record are mechanisms and modifiers. Mechanisms like ip4:, ip6:, include:, a, mx, and all define which servers are authorised to send email. Each mechanism can be prefixed with a qualifier: + (pass), - (fail), ~ (softfail), or ? (neutral). If no qualifier is specified, + is assumed.
Common syntax mistakes that our SPF syntax validator catches include: using spf1 without the v= prefix, adding extra spaces inside mechanisms (e.g., include: _spf.google.com instead of include:_spf.google.com), using deprecated ptr mechanisms, placing mechanisms after the all terminator where they're never evaluated, and using CIDR notation incorrectly in IP ranges. These errors won't throw a visible error; your emails will simply fail authentication checks without warning.
A well-formed SPF record for a domain using Google Workspace and a transactional email service might look like: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all. Notice the single space between each mechanism, no trailing spaces, the version tag first, and the strict -all at the end. This record is clean, concise, and well within the 10 DNS lookup limit.
SPF syntax validation is the first step in a complete email security audit. Once your record is syntactically correct, you should also verify that it works with DKIM signing and a DMARC policy to form the full email authentication triad. For a comprehensive assessment of your domain, run a full domain security scan.
Type your domain name in the search box above. Just enter the bare domain like example.com, no need for "www" or "https".
We query your domain's DNS TXT records and extract the SPF record. If multiple TXT records exist, we identify the one starting with "v=spf1".
Every mechanism, qualifier, modifier, and IP range is parsed token by token and validated against the RFC 7208 specification for correct syntax and formatting.
You receive a detailed breakdown of each syntax element with colour-coded results: valid mechanisms, warnings for deprecated usage, and errors with specific fix instructions.
Whether you're looking for an SPF syntax validator to verify a record you've just written, need to check SPF record syntax after migrating email providers, or want an SPF record format checker to audit your existing DNS entries, this tool does it all. We parse your record against the full RFC 7208 grammar, catching issues that generic DNS tools miss: malformed CIDR prefixes, invalid mechanism arguments, duplicate modifiers, and misplaced terminators.
IT administrators, DevOps engineers, and email deliverability specialists use our syntax checker as part of their deployment workflow. Before publishing an SPF record change to production DNS, validate the syntax here first. A single typo in an SPF record can cause legitimate email to land in spam or get rejected entirely, and because SPF failures are often silent, you may not notice the problem for days. Run your record through our SPF checker for a complete policy analysis beyond just syntax.
The most common SPF syntax errors include missing the required "v=spf1" version tag at the start of the record, using uppercase "V=SPF1" instead of lowercase, placing mechanisms after the "all" terminator (which are silently ignored), adding spaces before or after colons in mechanisms like "include: example.com" instead of "include:example.com", and publishing the record as a non-TXT DNS record type. Our SPF syntax checker detects all of these formatting mistakes instantly.
The "v=spf1" tag is a mandatory version identifier defined by RFC 7208. It must appear at the very beginning of your TXT record with no leading whitespace. This tag tells receiving mail servers that the TXT record is an SPF policy rather than some other type of TXT record. Without this exact prefix, mail servers will not recognise the record as a valid SPF policy at all, and your domain will be treated as having no SPF record, leaving it vulnerable to spoofing.
Syntax is just step one. Our full SPF checker also validates DNS lookups, policy strength, and included domains.
Yes, mechanism order matters significantly. SPF records are evaluated left to right, and the first mechanism that matches the sending server's IP address determines the result. For performance and clarity, place your most frequently used senders (like your primary mail provider's "include:") first, followed by less common entries. The "all" mechanism should always be the last item in the record since any mechanisms after it are never evaluated. Placing "all" anywhere other than the end is a common syntax mistake.
SPF qualifiers are single-character prefixes that define the policy action for each mechanism. "+" (pass) explicitly authorises the sender and is the default if no qualifier is specified, so "include:" and "+include:" are identical. "-" (fail/hard fail) means the sender is not authorised and email should be rejected. "~" (softfail) indicates the sender is probably not authorised but the email should be accepted and flagged. "?" (neutral) means no assertion is made either way. Best practice is to use "-all" at the end of your record for the strictest protection.
A single DNS TXT record string is limited to 255 characters by the DNS protocol. However, SPF records can exceed this by using multiple strings within the same TXT record, which the receiving server concatenates. The practical combined limit for an SPF record is 450 characters to stay safe, though some implementations handle up to 4,096 bytes. The real constraint is the 10 DNS lookup limit, and exceeding this causes a PermError regardless of record length. If your SPF record is growing too long, flatten nested includes into ip4: and ip6: mechanisms to reduce both length and lookup count.