Free SPF Syntax Validator
Validate SPF syntax against RFC 7208, count DNS lookups, flatten includes, get fix suggestions. Bulk mode for up to 100 domains.
Need something simpler? If you just want to check what your SPF says, use the SPF Checker. To build a record from scratch, use the SPF Generator. This validator is for deep audits — lookup limits, best-practice scoring, and one-click flattening.
We'll fetch the SPF record live and walk through every `include:`.
How it works
Pick an input mode
Single domain (lookup live), Paste record (validate a string you're about to publish), or Bulk (up to 100 domains at once).
Review the validation result
Status banner shows valid / warnings / invalid. Below: lookup-count meter (out of 10), best-practices score (out of 100), full mechanism breakdown with the include tree.
Apply fixes
Specific fix suggestions appear for any failed checks. If you're over the 10-lookup limit, click Flatten to compress includes into raw IPs. Copy the corrected record and publish.
What this validates beyond a basic SPF check
If all you need is "does my domain have SPF and what does it say," use our SPF Record Checker — it does a quick TXT lookup and parses the mechanisms. If you're publishing a NEW SPF record, our SPF Record Generator builds one for you with the right `include:` for Google, Microsoft, Mailchimp, SendGrid, and others.
This tool — the validator — goes deeper. It recursively resolves every `include:` chain to count your DNS lookups against the RFC 7208 limit of 10, scores your record against 8 best-practice checks, suggests specific fixes when something's wrong, and offers one-click flattening to compress over-limit records into a single flat list of IPs.
The 10-DNS-lookup limit (and why it breaks email)
RFC 7208 §4.6.4 says receiving mail servers must NOT perform more than 10 DNS lookups while evaluating an SPF record. Each `include:`, `a`, `mx`, `exists`, `ptr`, and `redirect` mechanism counts as one. Hit 11 and the receiver returns a PermError — SPF is treated as if it doesn't exist for your domain.
This breaks more email than you'd think. A typical fast-growing company starts with one `include:_spf.google.com` (4 nested lookups), adds `include:spf.mandrillapp.com` for transactional mail (3 more), then `include:_spf.salesforce.com` for sales sequences (4 more). That's 11 — your SPF is now broken and you didn't change a thing. The provider made the change inside their own record.
How you find out
Usually the wrong way: your emails start landing in spam or bouncing weeks after the change. The receiving server's PermError is silent from your side. Run any domain through this validator before AND after adding a new email provider.
How to read your SPF record
A typical SPF record looks like this:
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:mailchimp.com -allDecoded left to right:
- `v=spf1` — version header. Required. Receivers see this and know to parse the rest as SPF.
- `ip4:203.0.113.0/24` — authorizes the /24 block. Zero DNS lookups.
- `include:_spf.google.com` — delegates to Google's SPF record. Counts as 1 lookup at this level, plus whatever's nested inside Google's record.
- `include:mailchimp.com` — same idea, for Mailchimp.
- `-all` — terminal mechanism. The `-` means Fail: anyone NOT listed above gets rejected.
The four `all` qualifiers — and which to use
| Qualifier | Name | What it tells receivers | When to use |
|---|---|---|---|
| `-all` | Fail (strict) | Reject unauthorized senders outright | Production, after testing |
| `~all` | SoftFail | Accept but flag (often → spam folder) | Initial rollout, staging |
| `?all` | Neutral | No opinion — receiver does what they want | Rarely useful |
| `+all` | Allow All | Accept anyone as you | Never. This is spam waiting to happen. |
Practical path: start with `~all` for the first week to confirm legitimate senders aren't being flagged, then tighten to `-all`. Avoid `?all` — it gives receivers no actionable info. Never `+all`.
Why `+all` is dangerous
We've seen real attacks where a misconfigured SPF with `+all` let spammers send phishing email AS the company's domain to its own customers. Receivers checked SPF, saw `+all` (allow anyone), and delivered the spoofed email to the inbox.
`+all` defeats the entire point of SPF. If you ever see it on a domain you control, it almost certainly got pasted in by accident — change it to `-all` or `~all` immediately and check whether anyone exploited the window.
Why `ptr` is deprecated
RFC 7208 §5.5 explicitly recommends against the `ptr` mechanism. It triggers a reverse DNS lookup followed by a forward lookup — slow, easy to fool, and often blocked by network admins as DNS abuse.
Modern receivers (Gmail, Outlook, Yahoo) often skip `ptr` evaluation entirely or treat it as a void lookup. If your SPF uses it, replace it with explicit `ip4:` ranges (or an `include:` of your provider's SPF).
SPF flattening — when to use it, when to avoid it
Flattening means resolving every `include:` in your SPF down to its constituent `ip4:` / `ip6:` mechanisms. The output looks like a long flat list:
v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ... -allZero DNS lookups at evaluation time. RFC 7208's 10-lookup limit becomes irrelevant.
The trade-off
Your providers occasionally rotate IPs. Google adds a new /24 to `_spf.google.com`, Mailchimp adjusts its ranges, etc. A normal `include:` automatically picks up the new ranges. A flattened record doesn't — until you re-flatten and republish your DNS.
When to flatten: when you're over the 10-lookup limit and need an immediate fix. Set a calendar reminder to re-validate every 3 months — when providers update their IP lists, you'll catch the drift before delivery suffers.
When NOT to flatten: when you're under the limit. Includes are easier to maintain. Flatten only when forced to by the lookup count.
Multi-provider SPF — combining several senders in one record
A common shape we see: a B2B company sends marketing through Mailchimp, transactional through SendGrid, sales sequences through Outreach, and one-off emails directly from Google Workspace. The SPF needs to authorize all four. The right syntax:
v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com include:outreach.io -allOrder doesn't matter functionally — receivers evaluate left to right but accept the first match. Keep the most-active sender first as a tiny performance optimization (we're talking microseconds, but the convention is real).
Our SPF Record Generator handles the syntax of combining multiple providers if you'd rather build the record interactively than write it by hand.
SPF, DKIM, DMARC — how they fit together
SPF on its own isn't enough. The full deliverability stack is three records working together:
- SPF (this tool's focus) — says "these IPs / providers are authorized to send mail for my domain."
- DKIM — cryptographically signs each outgoing message so receivers can verify it wasn't tampered with. Check yours with our DKIM Record Checker.
- DMARC — tells receivers what to do when SPF or DKIM fails (reject, quarantine, or just monitor), and where to send compliance reports. Audit yours with our DMARC Record Checker.
All three need to be set up correctly for Gmail and Yahoo's bulk-sender requirements (2024+). Missing or broken SPF cascades into DMARC failures, which cascades into deliverability problems. Run this validator first, then check DKIM, then check DMARC.
Quick path for a new domain
1. Generate an initial SPF with our SPF Generator. 2. Publish to DNS, then verify with our SPF Checker. 3. Come back here to validate against the 10-lookup limit and best practices before you add new providers.
Frequently Asked Questions
Common questions about SPF lookup limits, all-mechanisms, flattening, and how this differs from our basic SPF tools.
RFC 7208 §4.6.4 says receiving mail servers must not perform more than 10 DNS lookups while evaluating an SPF record. Each `include:`, `a`, `mx`, `exists`, `ptr`, and `redirect` counts as one. The lookups inside each `include:`'s own record also count. Exceeding 10 returns PermError — your SPF is treated as if it doesn't exist for that evaluation.
`-all` (Fail) tells receivers to reject unauthorized senders — strictest. `~all` (SoftFail) accepts but flags them — common during initial rollout. `?all` (Neutral) means "no opinion" — receivers do whatever they want. `+all` (Allow All) tells receivers anyone can send as you — dangerous, never use. Production should land on `-all` after you've confirmed legitimate senders work.
No. RFC 7208 §3.2 explicitly says a domain must publish exactly one SPF record. Multiple `v=spf1` TXT records cause receivers to PermError — SPF evaluation fails completely. If you need to combine senders, merge them into a single record using `include:` mechanisms. This validator flags multiple records when it finds them.
Flattening recursively resolves every `include:` down to its raw `ip4:` / `ip6:` mechanisms. Result: zero DNS lookups, the 10-lookup limit becomes irrelevant. The trade-off: your providers' IP changes don't auto-propagate to your flattened record. Safe to use when you're over the limit, but you need a process to re-flatten every few months to catch IP drift. Don't flatten if you're under the limit — `include:` is easier to maintain.
RFC 7208 §5.5 recommends against `ptr` for several reasons: it requires reverse DNS lookups (slow), it's easy to spoof, and many network admins block reverse-DNS-abuse patterns at the resolver level. Modern receivers often skip `ptr` evaluation entirely. Replace it with explicit `ip4:` / `ip6:` ranges, or `include:` your provider's published SPF.
Different depth. The [SPF Record Checker](/spf-record-checker) does a quick TXT lookup and shows you the parsed mechanisms — perfect for "is my SPF live and what does it say." This validator recursively resolves every `include:` chain to count lookups against the 10-limit, scores the record against 8 best-practice checks, suggests specific fixes, and offers one-click flattening. Different use case, different audience. Use the checker first, the validator when you want depth.
Yes — that's what "Paste record" mode is for. Type or paste the record string (e.g. `v=spf1 include:_spf.google.com ~all`) into the textarea, click Validate, get the same lookup count + score + fix suggestions without publishing anything. Useful for catching the 10-lookup violation BEFORE you push the record to DNS.
Receiving mail servers return PermError when SPF evaluation exceeds the limit (RFC 7208 §4.6.4). PermError is functionally equivalent to "this domain has no SPF." Receivers fall back to their default policy — usually softer than your intended `-all`. DMARC alignment that depends on SPF passing also fails. Net effect: more of your legitimate mail lands in spam, and DMARC reports start showing failures.
Still have questions?
Contact our support team →SPF clean? Make sure your list is too.
Even with perfect SPF, bouncing emails wreck your sender reputation. Verify your list before sending — 200 free credits with no card on signup.