SPF Syntax Validator

Perform a detailed syntax and integrity check on your SPF records.

Evidence ASSESSED

Checked against: SPF TXT record with include/redirect expansion and the 10-lookup limit · RFC 7208

RED TEAM 0 findings BLUE TEAM control did not hold

Why validate SPF?

SPF (Sender Policy Framework) is prone to syntax errors and infrastructure limits. Validating your record ensures:

Lookup Limit: Records exceeding 10 DNS lookups will result in a PermError and fail SPF checks.
Syntax Integrity: Invalid mechanisms or typos can cause your entire record to be ignored by receiving mail servers.
Best Practices: Identifies overly permissive configurations like +all which increase spoofing risk.

Our SPF Record Validator goes beyond retrieving your record. It recursively expands every include, redirect and a/mx mechanism, counts the DNS lookups against the hard limit of ten, and reports every syntax error that would cause receivers to discard your SPF policy.

What is SPF Validation?

SPF (Sender Policy Framework) declares which servers may send mail for your domain. Publishing a record is straightforward; publishing a record that actually works is harder, because SPF has strict limits that fail silently.

The most important is the ten DNS lookup limit defined in RFC 7208. Every include, a, mx, ptr, exists and redirect mechanism costs a lookup, and includes nest — a single include pointing at a provider may itself consume four or five. Exceed ten and receivers return permerror, at which point your SPF policy is treated as though it does not exist.

Validation means evaluating the record the way a receiving server would: expanding the whole tree, counting the lookups, and checking every mechanism and qualifier for syntax that parsers will reject.

Recursively expands includes to count real DNS lookups
The RFC 7208 limit is ten lookups; exceeding it voids the record
A permerror means receivers ignore SPF entirely
Also enforces the separate limit of two void lookups
Catches syntax errors that silently disable the policy

Why SPF Validation Matters

An over-limit SPF record is worse than no record at all, because it looks correct in every control panel while providing zero protection. Nothing warns you. Mail keeps flowing, because most receivers deliver on permerror rather than reject, and the failure only becomes visible when DMARC enforcement starts rejecting legitimate mail.

The limit is easy to breach without noticing. Adding one more marketing platform to an SPF record that already includes a mail provider, a CRM and a helpdesk is often the change that pushes a working record over the edge.

Exceeding ten lookups causes permerror and disables SPF completely
The failure is silent — no bounce, no warning, no log entry
Breaks the SPF half of DMARC alignment, weakening enforcement
Adding one routine sender is frequently what crosses the limit
Multiple SPF records on one domain invalidate each other

How This SPF Validator Works

The tool evaluates your record exactly as a receiving mail server would, following every reference to its conclusion.

Validates the domain input against format and SSRF safety checks
Retrieves the SPF TXT record and confirms only one exists
Recursively resolves every include, redirect, a and mx mechanism
Counts the total DNS lookups against the limit of ten
Reports syntax errors, deprecated mechanisms and the final qualifier

How to Use the SPF Validator

Enter your domain name in the input field
Run the validation to expand the full mechanism tree
Check the DNS lookup count first — it must be ten or fewer
Review each expanded include to see which senders are authorised
Confirm the record ends in ~all or -all, not +all

Understanding Your SPF Validation Results

Validation reports the lookup count, the expanded tree and the policy qualifier. Here is what each means:

Field / Value	Meaning
`Lookup count`	Total DNS queries required to evaluate the record. Ten is the hard limit. Anything above it produces a permerror at receiving servers and SPF is ignored.
`include:`	Delegates to another domain SPF record. Costs one lookup, plus every lookup inside the included record. This nesting is where most limit breaches originate.
`ip4: / ip6:`	Authorises an address or CIDR range directly. These cost no DNS lookups at all, which makes them the primary tool for reducing an over-limit record.
`a / mx`	Authorises the addresses in the domain A or MX records. Each costs one lookup. Often removable if the addresses are already covered by an ip4 entry.
`~all`	Softfail. Mail from unlisted servers is accepted but marked suspicious. The right choice while you are still identifying legitimate senders.
`-all`	Hardfail. Mail from unlisted servers should be rejected. The correct end state once you are confident every sender is listed.
`+all`	Authorises every server on the internet to send as your domain. Effectively a misconfiguration, and it should be removed immediately.
`ptr`	Deprecated by RFC 7208. It is slow, unreliable and many receivers ignore it. Remove it and replace with ip4 or ip6 entries.

Common Problems & How to Fix Them

Receivers return permerror and disregard your SPF record entirely.

Reduce the count by replacing includes with the explicit ip4 and ip6 ranges they resolve to, since address mechanisms cost no lookups. Remove includes for services you no longer use, and drop redundant a and mx mechanisms whose addresses are already covered.

For complex setups, an SPF flattening service maintains the expanded ranges automatically — at the cost of a dependency on that service keeping up with provider IP changes.

Only one record beginning with v=spf1 is permitted. A second one causes permerror and both are discarded.

Merge every mechanism into a single record. Two records reading "v=spf1 include:_spf.google.com ~all" and "v=spf1 include:sendgrid.net ~all" combine into "v=spf1 include:_spf.google.com include:sendgrid.net ~all".

This authorises every mail server on the internet to send as your domain, which defeats the entire purpose of publishing SPF.

Change it to ~all while you confirm your legitimate senders, then to -all once you are confident the list is complete.

RFC 7208 explicitly deprecates ptr. It is slow, places load on reverse DNS infrastructure, and several major receivers ignore it entirely.

Remove it and authorise those servers with explicit ip4 or ip6 entries instead.

This produces a void lookup. SPF permits at most two, and exceeding that is another route to permerror.

Remove includes for services that have been decommissioned or that never published an SPF record. Each one is pure cost with no benefit.

Best Practices

Keep the DNS lookup count well below ten to leave room for future senders
Prefer ip4 and ip6 mechanisms over includes where the ranges are stable
Maintain exactly one SPF record per domain
Start with ~all and move to -all once every legitimate sender is confirmed
Audit the record whenever you add or remove an email vendor
Remove includes for services you have stopped using
Publish a restrictive SPF record on domains that send no mail at all

Security Recommendations

Never use +all, which authorises the entire internet to send as your domain
Treat permerror as a security failure, since an invalid record leaves you with no SPF protection whatsoever
Audit every include, because you are trusting that provider to authorise senders responsibly on your behalf
Publish v=spf1 -all on parked and non-sending domains to prevent them being used for spoofing
Pair SPF with DKIM, since SPF alone breaks on forwarding and cannot survive a changed connecting server
Review DMARC aggregate reports for SPF failures that reveal unauthorised senders using your domain

Frequently Asked Questions

RFC 7208 caps the number of DNS lookups required to evaluate an SPF record at ten. Each include, a, mx, ptr, exists and redirect mechanism counts, and includes nest. Exceeding the limit causes a permerror, and receivers then treat the domain as having no SPF record.

Replace includes with the explicit ip4 and ip6 ranges they resolve to, since address mechanisms cost no lookups. Remove includes for unused services, and drop a and mx mechanisms whose addresses are already covered. SPF flattening services automate this at the cost of a dependency.

It is a permanent evaluation error, usually caused by exceeding the lookup limit, by having two SPF records, or by a syntax mistake. Receivers treat a permerror domain as having no SPF policy, so the record provides no protection at all.

Softfail (~all) tells receivers to accept mail from unlisted servers but mark it suspicious. Hardfail (-all) tells them to reject it. Start with ~all while identifying your senders, then move to -all once the list is complete.

No. Only one record beginning with v=spf1 is permitted per domain. A second one causes a permerror and both are discarded. Merge all mechanisms into a single record instead.

It reliably solves the lookup limit, but it replaces a dynamic reference with a static snapshot. If a provider changes its sending IP ranges, your flattened record becomes wrong and legitimate mail starts failing. Use a service that refreshes automatically, and monitor the result.

Yes. DMARC can align against either SPF or DKIM, and having both gives you a working path when one fails. Google and Yahoo bulk sender requirements also expect both to be in place.