An SPF record error can prevent receiving mail servers from correctly verifying whether your domain is authorized to send an email. Common problems include SPF Fail, PermError, SoftFail, missing SPF records, multiple TXT records, and DNS lookup-limit errors. If your emails are failing authentication or you're seeing SPF validation errors in Google Workspace or Microsoft 365, identifying the exact cause is the first step toward fixing the problem.
Sender Policy Framework (SPF) helps receiving mail servers identify which IP addresses and services are authorized to send email on behalf of your domain. However, even a correctly configured SPF record can stop working when you add a new email provider, change DNS settings, or exceed the permitted DNS lookup limit.
In this guide, you'll learn how to diagnose common SPF errors, understand different SPF authentication results, fix PermError and HardFail issues, troubleshoot Microsoft 365 validation problems, and verify your DNS configuration using practical commands and online testing tools.
Whether you're managing a single business domain or dozens of cold email inboxes, this guide will help you identify SPF configuration problems and maintain properly authenticated email infrastructure.
💡 TL;DR
SPF record errors break cold email deliverability silently — your emails get delivered to the server but fail authentication and land in Spam or Junk. The most common errors are TooManyDNSLookups (over 10 mechanisms), duplicate SPF records (only one TXT record allowed per domain), missing include for your sending provider, and mismatched domain configuration. Fix SPF errors using MXToolbox's SPF checker, flatten mechanisms that exceed the DNS lookup limit, and always validate with a test send before resuming campaigns. Pre-warmed inboxes with SPF, DKIM, and DMARC pre-configured — like Litemail's — remove this entire category of setup errors.
What SPF Actually Does — And Why Getting It Wrong Is So Costly
SPF — Sender Policy Framework — is a DNS record that tells receiving mail servers which IP addresses are authorised to send email for your domain. When a mail server receives an email from you, it checks your SPF record. If the sending IP isn't on the list, the email fails SPF validation.
What happens next depends on your DMARC policy. With DMARC set to p=none, failed SPF just gets noted. With p=quarantine or p=reject, failed SPF means Junk folder or rejection. Gmail and Outlook both factor SPF failures into their spam scoring even when DMARC is set to p=none — the failure signal still affects placement.
SPF Result | Meaning | Gmail Impact | Outlook Impact |
|---|---|---|---|
Pass | Sending IP is authorised | No penalty | No penalty |
Fail (hard) | Sending IP explicitly rejected | Spam or rejected | Junk or rejected |
SoftFail (~) | IP not authorised but not hard-rejected | Spam scoring increase | Junk scoring increase |
PermError | Record has syntax error or too many lookups | Treated as fail | Treated as fail |
TempError | DNS lookup failed temporarily | Retry, may defer | Retry, may defer |
None | No SPF record found | No authentication | No authentication |
PermError is the silent killer. It happens when your SPF record exceeds 10 DNS lookups and gets treated as a hard failure by receiving servers. Your email gets "delivered" to the server — which is why your sending tool shows 99% delivery — but fails authentication and lands in Spam. This is why delivery rate is a useless primary metric.
Common SPF Errors and How to Fix Them
SPF Error | Common Cause | Recommended Fix |
|---|---|---|
SPF PermError | Invalid syntax, multiple records or lookup-limit problems | Correct the SPF policy |
SPF Fail | Sending IP is not authorized | Verify and authorize the legitimate sender |
SPF SoftFail | Sender does not match an authorized mechanism with | Review the sending source and SPF policy |
No SPF Record Found | Missing or incorrect SPF policy | Publish an appropriate SPF TXT record |
Multiple SPF Records | More than one applicable SPF policy | Consolidate authorized mechanisms |
SPF Lookup Limit Exceeded | More than 10 DNS-querying terms | Reduce unnecessary DNS lookups |
SPF TempError | Temporary DNS resolution problem | Check DNS availability and retry |
Invalid SPF Syntax | Incorrect mechanisms or formatting | Correct the record and validate again |
Note: An SPF result describes authentication, not necessarily the final inbox or spam decision.
The 6 Most Common SPF Record Errors and Their Fixes
These are the errors that show up most in MXToolbox diagnostics and DMARC report data. Each one has a specific fix that takes under 30 minutes to implement once you know what you're looking at.
🔴
Error 1 — TooManyDNSLookups (over 10 mechanisms)
SPF allows a maximum of 10 DNS lookup mechanisms per record. Each include:, a:, mx:, and ptr: counts as a lookup. When you add multiple sending tools (Google, Outlook, Mailchimp, Sendgrid, your cold email tool), you easily hit 12 to 15 lookups. Fix: use an SPF flattening tool like AutoSPF or dmarcly.com to replace nested includes with their resolved IP addresses. The resulting record stays under 10 lookups regardless of how many IP ranges you need to include.
🔴
Error 2 — Multiple SPF records on the same domain
A domain can only have one SPF TXT record. If you have two (which happens when someone adds a second SPF record instead of editing the existing one), the result is a PermError — both records are ignored. Fix: check your DNS for multiple TXT records starting with "v=spf1". Delete all but one and merge all your authorised senders into that single record.
🟡
Error 3 — Missing include for sending tool
When you add a new sending tool — a cold email platform, a marketing email service — but forget to add its include: mechanism to your SPF record, emails from that tool will fail SPF. Fix: check your sending tool's documentation for its required SPF include statement, add it to your existing SPF record, and save. Verify with MXToolbox. This is often why a new campaign platform suddenly produces high spam rates even with a previously clean domain.
🟡
Error 4 — SoftFail (~all) when hard Fail (-all) is needed
Most SPF records end with ~all (soft fail) rather than -all (hard fail). For cold email domains, -all is actually better — it clearly rejects mail from unauthorised sources, which strengthens your domain's authentication posture. SoftFail is a legacy setting that was designed for transition periods. If your SPF record is complete and correct, use -all for maximum deliverability signal.
🟡
Error 5 — Wrong domain in the SPF record
SPF records must be on the exact domain in the From: header. If you're sending from john@outreach.yourcompany.com but your SPF record is only on yourcompany.com, SPF will fail for the subdomain. Fix: add a separate SPF TXT record for each subdomain you send from, or configure your DNS to include subdomain sending in the parent record.
🟠
Error 6 — PTR mechanism in SPF (deprecated)
The ptr: mechanism in SPF is deprecated and unreliable. Some older SPF records still include it, which wastes one of your 10 DNS lookups and can cause unexpected failures. Fix: remove any ptr: mechanisms from your SPF record. Replace the intent (authorising an IP or range) with a direct ip4: or ip6: mechanism instead.
Understanding SPF Results: Pass, Fail, SoftFail, PermError and TempError
Before fixing an SPF problem, understand what the result actually means. Different SPF results indicate different problems, and each requires a different troubleshooting approach.
SPF Result | Meaning | What to Do |
|---|---|---|
Pass | The sending IP is authorized | No SPF correction is required |
Fail | The sending IP is not authorized | Check the sending source and SPF mechanisms |
SoftFail | The IP is not authorized, but the policy marks it as a soft failure | Review whether the sender should be authorized |
Neutral | The SPF record makes no definitive authorization statement | Review the final qualifier |
None | No applicable SPF record was found | Check the correct sending domain and publish SPF if required |
PermError | The SPF record cannot be evaluated correctly | Check syntax, duplicate records and DNS lookup limits |
TempError | A temporary DNS or evaluation problem occurred | Check DNS availability and retry |
A critical distinction is that SPF Fail and SPF PermError are not the same.
A Fail result means the evaluated sender was not authorized by the published policy. A PermError means the SPF policy itself could not be correctly evaluated.
RFC 7208 defines these results and their handling. A receiver's final decision also depends on its own mail policy and DMARC evaluation.
How to Fix SPF PermError
SPF PermError means the receiving mail server could not correctly evaluate your published SPF policy. It requires investigating the DNS record rather than simply changing the final qualifier.
Step 1: Check for multiple SPF records
Run:
Look for TXT records beginning with:
You should have only one applicable SPF policy at that DNS name.
If you find multiple SPF records, combine the legitimate sending mechanisms into one record instead of publishing separate SPF policies.
Step 2: Check the DNS lookup limit
SPF evaluation allows a maximum of 10 DNS-querying terms. These include:
include:
a
mx
ptr
exists
redirect=
Nested includes also consume lookup capacity.
Review the complete SPF evaluation tree rather than counting only the visible mechanisms in your record.
Step 3: Check invalid includes
A missing or incorrectly formatted include can cause PermError.
For example, this is incorrect:
The correct syntax is:
Also verify that the included domain publishes a valid SPF policy.
Step 4: Check syntax and formatting
Look for:
Missing spaces between mechanisms
Incorrect colons or equals signs
Invalid qualifiers
Unsupported mechanisms
Incorrect domain names
Unnecessary duplicate mechanisms
Step 5: Validate again
After making corrections, check the record using an SPF validator and test a real message.
Do not assume the problem is fixed simply because the DNS record is visible. Confirm the SPF result in the receiving server's Authentication-Results header.
How to Fix SPF Validation Errors in Office 365
An SPF validation error in Microsoft 365 can occur when the domain has an incorrect SPF record, multiple SPF policies, missing authorized senders, or an invalid third-party include.
For a Microsoft 365-only sending setup, Microsoft's commonly documented SPF record is:
This is an example for a domain whose only authorized outbound sender is Microsoft 365. If other services send email using the same domain, their approved sending sources must also be considered.
Troubleshooting steps
Open your DNS provider's management panel.
Locate the TXT records for the sending domain.
Find the existing SPF record.
Confirm there is only one applicable SPF policy.
Check that the Microsoft 365 include is spelled correctly.
Add other legitimate sending services only when required.
Save the DNS changes.
Run an SPF validation check.
Send a test email and inspect its Authentication-Results header.
Important: Do not publish a second SPF record simply to add Microsoft 365. Modify the existing policy carefully.
Official Microsoft guidance: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure
How to Fix the No SPF Record Found Error
The error "No SPF Record Found" generally means the receiver could not find an applicable SPF policy for the domain it evaluated.
First, confirm which domain is being checked. SPF normally evaluates the envelope sender (MAIL FROM) domain, which may differ from the visible From address.
Run:
Or:
If there is no applicable SPF record:
Identify every legitimate service sending email for the domain.
Obtain the correct SPF mechanisms from each provider's official documentation.
Combine the approved mechanisms into one SPF record.
Publish the record as a DNS TXT record.
Validate it using an SPF checker.
Send a test email and inspect authentication results.
Never copy an SPF record from another business without checking its actual sending infrastructure.
SPF Fail vs Hard Fail vs SoftFail
These terms are related but describe different parts of SPF evaluation.
Term | Meaning |
|---|---|
SPF Fail | The evaluated sender is explicitly unauthorized |
Hard Fail (-all) | The final SPF mechanism returns Fail |
SoftFail (~all) | The final SPF mechanism returns SoftFail |
The all mechanism matches any sender that has not matched an earlier mechanism.
For example:
This authorizes the example IP and explicitly fails other unmatched senders.
A soft-fail example is:
This marks other unmatched senders as SoftFail.
Neither qualifier independently guarantees better inbox placement. Before switching from ~all to -all, confirm that every legitimate sending service is authorized.
How to Check SPF Using dig and nslookup
You can inspect an SPF record without relying entirely on online validation tools.
Using dig
Using nslookup
Check a specific sending provider
Check the Google Workspace SPF include
What to verify
The record starts with
v=spf1.Only one SPF policy is published at the relevant domain.
All legitimate sending services are authorized.
The evaluated lookup count stays within the RFC limit.
There are no syntax or include errors.
The final qualifier reflects your intended policy.
For deeper analysis, use MXToolbox or another SPF validator that displays recursive lookup information.
Fixing the TooManyDNSLookups Error: Step by Step
The TooManyDNSLookups error is the most common SPF failure for active cold email operators because it compounds as you add tools. Here's the exact process to fix it.
1️⃣
Step 1 — Count your current DNS lookups
Go to mxtoolbox.com/spf.aspx and enter your sending domain. MXToolbox will show your current SPF record and flag if you've exceeded 10 lookups. It also shows a breakdown of each mechanism and how many lookups each one generates. Screenshot this before making changes — you'll need to know exactly what's in the record currently.
2️⃣
Step 2 — Identify mechanisms generating the most lookups
Common high-lookup mechanisms: include:_spf.google.com (counts as multiple due to nested includes), include:sendgrid.net, include:mailgun.org, and similar. Each of these may expand to 3 to 5 internal lookups when resolved. These are the candidates for flattening.
3️⃣
Step 3 — Flatten nested includes using AutoSPF or manual IP resolution
Run your current SPF record through AutoSPF or dmarcly.com's SPF flattener. The tool resolves all nested includes into their actual IP ranges and returns a flattened record that uses ip4: and ip6: mechanisms instead of include: chains. The flattened record typically has 2 to 4 lookups regardless of how many IP ranges it covers.
4️⃣
Step 4 — Update your DNS record and wait for propagation
Replace your existing SPF TXT record in your DNS provider (Cloudflare, GoDaddy, Route53, etc.) with the flattened version. DNS propagation typically takes 30 minutes to 4 hours, though it can be up to 48 hours in rare cases. Don't send campaigns while propagation is in progress.
5️⃣
Step 5 — Validate with MXToolbox before resuming sends
After propagation, run MXToolbox again. Confirm lookup count is under 10, confirm the record type shows \"Pass\" not \"PermError\", and send a test email to a seed inbox at Gmail, Outlook, and Yahoo to confirm authentication passes end-to-end. Only resume campaign sends after all three checks are clean.
How SPF Errors Interact With DKIM and DMARC
SPF, DKIM, and DMARC work as a system. An SPF failure doesn't automatically kill an email if DKIM passes — DMARC can be satisfied by either record passing (depending on your DMARC alignment setting). But this relationship has nuances that affect how you troubleshoot.
SPF Result | DKIM Result | DMARC Result | Inbox Outcome |
|---|---|---|---|
Pass | Pass | Pass | Inbox (best case) |
Fail | Pass | Pass (if DKIM aligned) | Usually inbox |
Pass | Fail | Pass (if SPF aligned) | Usually inbox |
Fail | Fail | Fail | Junk or rejected |
PermError | Pass | Partial pass | Mixed — depends on provider |
The practical implication: if you have a SPF PermError but DKIM is passing with proper alignment, you might not see a complete deliverability collapse — but you're still failing one of the two authentication checks, which affects your spam score. Fix the SPF error regardless of whether DKIM is currently compensating for it.
In practice, this means the DMARC aggregate reports (sent to the rua= address in your DMARC record) will show you exactly which records are passing and failing, at what volume, from which IPs. If you're not reading DMARC reports, you're managing authentication blind.
The Tools That Make SPF Troubleshooting Fast
SPF troubleshooting without the right tools takes hours. With them, it takes minutes. Here's the shortlist.
🔧
MXToolbox — primary SPF diagnostic
Free. Enter any domain and get a full SPF record parse including DNS lookup count, mechanism breakdown, and pass/fail status. The blacklist check is also valuable — run it any time you suspect IP reputation issues. Bookmark mxtoolbox.com/spf.aspx for your sending domains.
🔧
DMARC Analyzer — reading aggregate reports
DMARC reports come in XML format that's nearly unreadable raw. DMARC Analyzer (and dmarcly.com, Postmark's DMARC app) parse these reports into human-readable dashboards showing pass/fail rates by source IP. Essential for understanding where your authentication failures are actually coming from.
🔧
AutoSPF or dmarcly.com — SPF flattening
When your record exceeds 10 lookups, these tools automatically flatten the nested includes into direct IP ranges. AutoSPF also offers automatic updating — when a provider changes their IP ranges, your flattened record updates automatically, which prevents SPF failures from provider IP changes that you'd otherwise never know about until deliverability drops.
🔧
Google Admin Toolbox — end-to-end authentication testing
Send a test email to a Gmail address and then use Google's Messageheader tool to check the authentication results header. This shows you exactly what Gmail saw when it received your email — SPF result, DKIM result, DMARC result, and spam confidence score. It's the closest you can get to Gmail's actual filtering decision without being inside Google.
SPF Record Maintenance: Preventing Errors From Coming Back
Most SPF errors don't happen once. They recur — because someone adds a new sending tool, changes providers, or inherits a misconfigured record and doesn't know it. Build a maintenance habit that catches issues before campaigns go live.
📅
Monthly: run MXToolbox on all sending domains
Takes 10 minutes for 5 domains. Catches accumulated lookup creep before it hits the 10-mechanism limit. Run it on the first of every month as a calendar event. Don't rely on your sending tool to alert you to SPF failures — it won't always catch PermErrors that appear as delivery successes.
📅
Before any new sending tool: check lookup count first
Before adding a new cold email platform, warmup tool, or email service, check how many DNS lookups the new include: will add. If you're already at 8 or 9 lookups, adding another service will push you over the limit. Either flatten the existing record first or choose a provider that can be added as a direct IP range rather than an include: mechanism.
📅
After any DNS change: test before sending
Any DNS change — domain transfer, hosting change, nameserver update — can accidentally modify or delete SPF records. After any DNS change, run a full authentication check before resuming campaign sends. The 5-minute check prevents the 3-week recovery from a silently broken SPF record.
The Bottom Line
SPF PermError (from exceeding 10 DNS lookups) causes silent deliverability failure — emails get "delivered" to the server but fail authentication and land in Spam.
Only one SPF TXT record per domain is allowed — multiple records cause PermError. Merge all your authorised senders into a single record.
Fix TooManyDNSLookups by flattening nested includes using AutoSPF or dmarcly.com — the flattened record replaces include: chains with direct IP ranges.
Use -all (hard fail) instead of ~all (soft fail) on cold email sending domains — it clearly rejects unauthorised sources and strengthens your authentication posture.
DMARC aggregate reports (read via DMARC Analyzer or dmarcly.com) show exactly which authentication checks are passing and failing — read them monthly.
Run MXToolbox on all sending domains monthly and before every new campaign launch — DNS changes can silently break SPF without any obvious tool-side alert.
Pre-warmed inboxes with SPF, DKIM, and DMARC pre-configured remove this entire troubleshooting category — no manual DNS work, no setup errors, authentication correct from day one.
Frequently Asked Questions
What does SPF fail mean?
SPF fail means the sending IP address is not authorized by the SPF policy evaluated for the email's sending identity. Check the sending IP, the envelope sender domain, and the authorized mechanisms in your DNS record.
What causes an SPF PermError?
SPF PermError occurs when a published SPF record cannot be evaluated correctly. Common causes include multiple SPF records, invalid syntax, exceeding the 10 DNS-querying-term limit, and invalid or broken include mechanisms.
How do I fix an SPF validation error?
Start by checking your domain's TXT records. Confirm that only one SPF policy exists, verify its syntax, authorize all legitimate sending services, and stay within the SPF DNS lookup limit. Validate the updated record and test a real email.
What does SPF hard fail mean?
SPF hard fail occurs when the evaluated sender matches a mechanism with the - qualifier, commonly -all. It means the sending host is explicitly unauthorized under that SPF policy.
What is the difference between SPF SoftFail and HardFail?
SoftFail (~all) indicates that the sender is probably unauthorized, while HardFail (-all) explicitly marks unmatched senders as unauthorized. Both require correct authorization of legitimate sending sources.
How do I fix No SPF Record Found?
Check the actual envelope sender domain using a DNS TXT lookup. If there is no applicable SPF record, identify your legitimate sending providers and publish one correctly configured SPF TXT record.
Why does Office 365 show an SPF validation error?
Microsoft 365 SPF validation errors can result from incorrect syntax, multiple SPF records, missing authorized sending services, invalid includes, or lookup-limit problems. Check Microsoft's recommended SPF configuration and validate your domain's DNS.
Can multiple email providers use one SPF record?
Yes. Multiple legitimate sending providers can be authorized through one SPF record using their documented mechanisms. You must combine them into one policy and ensure the complete evaluation remains within SPF limits.
Does SPF failure automatically send an email to spam?
No. SPF failure does not automatically determine inbox placement. The receiving provider considers additional signals, including DKIM, DMARC alignment, sender reputation, and its own filtering policies.
Does SPF work with email forwarding?
Standard forwarding can cause SPF failures because the forwarding server's IP may not be authorized by the original sender's SPF record. Sender Rewriting Scheme (SRS) can help preserve SPF evaluation during forwarding. DKIM and DMARC alignment are also important.
