SPF Record Validator
Check your SPF record for errors and misconfigurations
SPF Quick Reference
Qualifiers
- + Pass (default) - Allow the email
- - Fail - Reject the email
- ~ SoftFail - Accept but mark suspicious
- ? Neutral - No policy statement
Key Limits
- 10 maximum DNS lookups per evaluation
- 255 characters per TXT string
- 512 bytes recommended max UDP response
- ptr deprecated in RFC 7208
About This Tool
Validate SPF (Sender Policy Framework) records against RFC 7208 rules. Checks syntax, mechanism validity, DNS lookup limits, policy strength, and common misconfigurations like duplicate includes, deprecated ptr usage, and redirect/all conflicts.
All validation runs in your browser. Domain lookups use our DNS infrastructure but the analysis itself is entirely local.
Related Tools
How SPF Validation Works
SPF (Sender Policy Framework) validation is the process a receiving mail server performs to verify whether an incoming email was sent from an authorised server. When an email arrives claiming to be from hello@netoz.au, the receiving server looks up the SPF TXT record for netoz.au in DNS, then checks whether the sending server's IP address is listed as an authorised source.
The validation produces one of several results:
- Pass — The sending IP is explicitly authorised. The email passes SPF authentication.
- Fail (-all) — The sending IP is not authorised and the domain has a strict policy. The email should be rejected.
- SoftFail (~all) — The sending IP is not authorised but the domain uses a lenient policy. The email is accepted but flagged as suspicious.
- Neutral (?all) — The domain makes no assertion about the sending IP. Treated as if no SPF record exists.
- PermError — The SPF record has a syntax error or exceeds the DNS lookup limit. Many receivers treat this as a failure.
- TempError — A temporary DNS failure prevented the lookup. The receiving server may retry later.
This validator fetches your domain's SPF record from DNS, parses the syntax against RFC 7208, resolves all include: chains, counts DNS lookups, and flags any issues that could cause validation failures. All lookups run from our Australian infrastructure for accurate results.
SPF Record Limits
SPF records have several built-in limits defined by the RFC. Exceeding any of these limits causes a permanent error (PermError), which most receiving servers treat as an SPF failure — potentially causing your legitimate emails to be rejected or sent to spam.
10 DNS Lookup Limit
The most common limit. SPF records can trigger a maximum of 10 DNS lookups during evaluation. Mechanisms that count include include:, a, mx, exists, ptr, and the redirect= modifier. Crucially, nested includes count too — if include:_spf.google.com itself includes three more domains, that's four lookups total. The ip4: and ip6: mechanisms do not count as they require no DNS resolution.
2 Void Lookup Limit
A void lookup occurs when a DNS query returns no records (NXDOMAIN or empty response). RFC 7208 limits void lookups to 2 — if exceeded, the result is a PermError. This prevents attackers from using SPF records to probe for non-existent domains.
512 Byte UDP Response Limit
While not strictly an SPF limit, DNS TXT records that exceed 512 bytes require TCP fallback, which can cause issues with some resolvers. SPF records should also stay under 255 characters per TXT string (though they can be split into multiple strings within a single record). Keeping your record concise by using ip4: ranges instead of individual IPs helps.
One SPF Record Per Domain
A domain must have exactly one SPF record (one TXT record starting with v=spf1). Having two or more SPF records causes a PermError. If you need to combine multiple sending sources, they must all be in a single record. This validator checks for duplicate SPF records automatically.
Common SPF Errors
Exceeding the 10 DNS Lookup Limit
This is the most frequent SPF error, especially for businesses that use multiple third-party email services. Each include: counts as at least one lookup, and nested includes add up quickly. For example, a record with Google Workspace, Microsoft 365, Mailchimp, and SendGrid could easily exceed the limit.
Fix: Replace include: mechanisms with direct ip4: entries where possible, use SPF record flattening, or consolidate sending services. Our SPF Record Builder tracks lookup counts in real time.
Multiple SPF Records
Publishing two or more TXT records that start with v=spf1 on the same domain causes a PermError. This commonly happens when an administrator adds a new SPF record without removing the old one, or when a third-party service adds their own SPF record alongside an existing one.
Fix: Merge all sending sources into a single SPF record. Use our DNS Lookup tool to check how many TXT records your domain currently has.
Using +all or ?all Policy
An SPF record ending with +all effectively authorises every server in the world to send email for your domain — making SPF completely useless. Similarly, ?all provides no protection. Some email providers will penalise domains using these policies.
Fix: Use ~all (softfail) while testing and migrate to -all (hard fail) once you've confirmed all legitimate senders are included.
Using the Deprecated PTR Mechanism
The ptr mechanism performs a reverse DNS lookup and is deprecated by RFC 7208 due to performance concerns and unreliability. Many receiving servers ignore it or penalise records that use it.
Fix: Replace ptr with explicit ip4: or a: mechanisms for the same servers.
Missing Sending Sources
If your SPF record doesn't include all the servers that legitimately send email for your domain, those messages will fail SPF. This commonly happens when a business adds a new email marketing tool, ticketing system, or CRM that sends on their behalf without updating the SPF record.
Fix: Audit all services that send email using your domain. Check your MX records and review email headers from different senders to identify all outbound IPs. Add each source to your SPF record using ip4: or include: mechanisms.