An incorrectly configured SPF record causes authentication failures that hurt your deliverability. Common issues include syntax errors, exceeding the DNS lookup limit, missing sending sources, and having multiple SPF records. This guide shows you how to validate your SPF configuration.
Quick SPF Check Using MXToolbox
- Go to mxtoolbox.com/spf.aspx
- Enter your domain name
- Click "SPF Record Lookup"
- Review the results for errors or warnings
The tool displays your SPF record, validates the syntax, counts DNS lookups, and flags any problems.
What to Check For
1. Record Exists
The most basic check: does your domain have an SPF record? If the lookup returns "No SPF record found," you need to create one.
2. Only One SPF Record
Your domain must have exactly one SPF record. Multiple SPF records cause a permerror result, failing authentication entirely. If you have multiple records, merge them into one.
3. Correct Syntax
SPF records must follow specific syntax rules:
- Starts with
v=spf1 - Mechanisms separated by spaces
- Ends with
allmechanism - No duplicate mechanisms
4. DNS Lookup Count
SPF allows a maximum of 10 DNS lookups. Each include:, a:, mx:, and redirect= mechanism counts as one lookup. Nested includes count too. Exceeding 10 lookups causes SPF to fail with a permerror.
The 10 Lookup Limit Is Strict
Once you hit 10 lookups, SPF evaluation stops and returns permerror. All subsequent mechanisms are ignored. This is a hard limit defined in the RFC specification.
5. All Sending Sources Included
Your SPF record must authorize every system that sends email as your domain. Missing sources cause SPF failures for legitimate mail. Common sources to include:
- Your own mail servers
- Google Workspace or Microsoft 365
- Marketing email platforms
- Transactional email services
- CRM and support systems
6. Proper All Mechanism
Your record should end with -all (hard fail) or ~all (soft fail). Never use +all, which authorizes anyone to send as your domain.
Testing SPF with Real Emails
Validation tools check your DNS record, but testing with real emails confirms everything works in practice:
- Send a test email from each sending system
- View the raw message headers in the recipient's inbox
- Find the Authentication-Results header
- Look for
spf=pass
If you see spf=fail or spf=softfail, the sending system's IP is not in your SPF record.
Using Command Line Tools
For technical users, you can query SPF records directly:
dig TXT example.com +shortThis returns all TXT records for the domain. Look for the one starting with v=spf1.
Common SPF Errors
permerror
Permanent error. Usually caused by syntax errors, multiple SPF records, or exceeding the lookup limit. SPF cannot evaluate the record at all.
temperror
Temporary error. Usually a DNS timeout or server issue. The receiving server should retry.
softfail (~all)
The sending IP is not authorized, but the policy suggests accepting the message with suspicion. This is less strict than hard fail.
fail (-all)
The sending IP is explicitly not authorized. With a hard fail policy, receivers should reject the message.
Regular SPF Audits
Check your SPF record whenever you:
- Add a new email sending service
- Change email providers
- Update your mail server infrastructure
- Notice authentication failures in DMARC reports
We recommend checking SPF at least quarterly, even without changes, to catch any configuration drift.