Validate and analyse SPF TXT records directly in your browser. Quickly detect syntax problems, understand what each mechanism does, and spot risky patterns before you publish or troubleshoot your email setup.
This tool is useful for sysadmins, email admins, and domain owners working with SPF policies for Google Workspace, Microsoft 365, mail gateways, or custom mail servers.
Validation summary
Parsed SPF parts
Normalized record
How to use
- Paste your SPF TXT record into the input field.
- Click Validate record.
- Review the summary, warnings, and actionable fixes.
- Check each parsed mechanism or modifier for explanation and context.
- Copy the normalised SPF record if needed.
FAQ
SPF validation help
An SPF record is a DNS TXT record that tells receiving mail servers which systems are allowed to send email for your domain. It helps reduce spoofing and improves email authentication.
If SPF is missing or misconfigured, legitimate mail can fail checks and fake mail can be harder to detect.
A minimal valid SPF record must start with v=spf1 and then define allowed senders or a final policy.
Example:
v=spf1 -allThis means no hosts are authorised to send mail for the domain.
These are SPF qualifiers:
+pass-fail~softfail?neutral
Example:
v=spf1 include:_spf.google.com ~allThis means Google is allowed, and everything else gets a softfail result.
The all mechanism is the catch-all rule. It should normally be the last SPF mechanism, because it applies to anything not matched before it.
Good example:
v=spf1 ip4:203.0.113.10 include:_spf.google.com -allProblematic example:
v=spf1 -all include:_spf.google.comIn the second case, the record logic becomes misleading and the tool will warn about it.
include: tells SPF to evaluate another domain’s SPF policy as part of yours.
Example:
v=spf1 include:_spf.google.com -allThis is common when using a third-party mail provider. The tool warns when too many lookup-causing terms are used, because SPF has practical DNS lookup limits.
redirect= tells SPF to use another domain’s SPF policy instead of continuing with the current one.
Example:
v=spf1 redirect=example.comThis is different from include:. It replaces the rest of the SPF logic, so it should be used carefully.
This means the record is structurally usable, but something looks risky or unusual.
Common warnings include:
allnot placed at the end- duplicate modifiers like
redirect= - too many lookup-causing mechanisms
- unknown or suspicious tokens
The tool shows each warning together with a recommended fix.
A common practical setup looks like this:
v=spf1 ip4:203.0.113.10 include:_spf.google.com -allThis allows one specific IPv4 sender and Google Workspace, then fails everything else.
Practical examples
Example 1 — strict custom sender
v=spf1 ip4:203.0.113.10 -allThis record allows only one IPv4 address to send mail for the domain. Everything else fails SPF.
Example 2 — Google Workspace with softfail
v=spf1 include:_spf.google.com ~allThis is common during rollout. Google is authorised, while all other senders get softfail instead of hard fail.
Example 3 — record with a warning
v=spf1 -all include:_spf.google.comThis record is structurally wrong in practice because all appears too early. The validator should warn that all should normally be the final mechanism.
Example 4 — lookup-heavy SPF
v=spf1 include:_spf.google.com include:spf.protection.outlook.com a mx exists:%{i}.spf.example.com ~allThis record may be valid, but it increases DNS lookup pressure. The tool highlights this so you can simplify the policy before it becomes fragile.