Table of Contents
Do not index
IntroductionThe 10 DNS Lookup LimitCommon SPF Errors and How to Fix EachSPF Record Best PracticesOther Things You Need to Know About SPF Errors
Introduction
SPF errors happen when your domain's Sender Policy Framework record is misconfigured in a way that prevents receiving servers from validating your emails. The most common error, SPF PermError from too many DNS lookups, occurs when your SPF record exceeds the 10 DNS lookup limit defined in RFC 7208. When this happens, DMARC interprets the result as a fail, and your emails get filtered to spam or rejected outright regardless of what they contain.
Every organization that uses multiple email services runs into this eventually. Google Workspace takes one lookup. SendGrid takes another. HubSpot adds one. Mailchimp adds one. Each include: statement in your SPF record triggers at least one DNS lookup, and the services themselves often contain nested includes that consume additional lookups. A company using five email services can easily reach 12 or 15 total lookups without realizing it, silently breaking SPF on every email they send.
The frustrating part is that SPF failures are invisible in most email dashboards. Your platform says "delivered." But on the receiving side, the SPF check returned PermError, DMARC evaluated it as a fail, and Gmail quietly moved the message to spam. Nobody on the sending side gets notified.
The 10 DNS Lookup Limit
RFC 7208, the specification that defines SPF, sets a hard limit of 10 DNS lookups per SPF evaluation. This limit exists to prevent Denial of Service attacks where a malicious SPF record could trigger hundreds of recursive DNS queries against receiving servers.
The mechanisms that count against the limit: include, a, mx, ptr (deprecated), exists, and the redirect modifier. Each of these triggers at least one DNS lookup. Nested includes count too; if your SPF record includes SendGrid, and SendGrid's SPF record includes three more domains, all of those count toward your 10.
The mechanisms that don't count: ip4, ip6, and all. These are resolved locally without DNS queries.
Use MXToolbox's SPF checker to see your current lookup count. If it shows more than 10, you're in PermError territory and every email from your domain is failing SPF.
Common SPF Errors and How to Fix Each
.png?table=block&id=34216483-6d68-80b5-8cbb-fa57c5e706d1&cache=v2)
PermError: Too Many DNS Lookups
This is the most common SPF failure. Your record has more than 10 DNS querying mechanisms.
Fix it by replacing include: statements with ip4: or ip6: ranges where possible. If a service uses static IPs, hardcoding them as ip4 entries saves a lookup without changing functionality. For services with dynamic IPs, SPF flattening tools like AutoSPF or DMARCLY's Safe SPF automatically resolve includes into IP ranges and keep them updated.
Multiple SPF Records
DNS allows only one SPF TXT record per domain. Publishing two (which often happens when different team members add records without checking) invalidates both. The receiving server sees two records and returns PermError.
Fix it by merging all sending sources into a single v=spf1 record. If two records exist, combine their mechanisms into one and delete the duplicate.
Syntax Errors
A missing v=spf1 prefix, a typo in a mechanism name, a missing space between mechanisms, or an improperly formatted IP range all cause the entire record to be treated as invalid.
Fix it by validating your record through MXToolbox or EasyDMARC's SPF lookup tool after every edit. One character out of place breaks the entire record.
Unresolvable Inclusion
An include: mechanism pointing to a domain that has no SPF record or returns a DNS error causes a PermError. This typically happens when you cancel a service but leave its include in your SPF record.
Fix it by removing includes for any service you no longer use. Audit your SPF record quarterly and cross reference each include against your active vendor list.
Missing Sending Source
A platform is sending email on your domain but isn't listed in the SPF record. Those emails fail SPF because the sending IP isn't authorized.
Fix it by adding the platform's include: statement or IP address to your SPF record. Most email services document their SPF requirements in their setup guides.
SPF Record Best Practices
Audit quarterly. Remove stale includes for services you've canceled. Each unnecessary include wastes a DNS lookup.
Use ip4/ip6 for static IPs. This is the most reliable way to reduce lookup count without losing authorization.
End with a hard fail. Use -all (hard fail) rather than ~all (soft fail). Hard fail tells receiving servers to reject unauthorized senders, not just flag them.
Test after every change. Use MXToolbox, EasyDMARC, or Google's SPF record checker to validate your record after each edit.
Monitor with DMARC reports. DMARC aggregate reports show SPF pass/fail rates across all your sending. They surface failures you wouldn't catch through your email platform's dashboard.
Mailwarm's infrastructure health check audits your SPF record alongside DKIM, DMARC, blacklists, and SMTP configuration, identifying issues before they affect your deliverability.
Other Things You Need to Know About SPF Errors
Can SPF errors affect my deliverability even if DKIM passes?
Yes. While DMARC only requires one of SPF or DKIM to pass with alignment, providers like Gmail evaluate both independently when scoring sender reputation. Consistent SPF failures degrade your domain's overall trustworthiness.
What's the difference between ~all and -all?
~all is a soft fail that tells receiving servers to accept but flag unauthorized emails. -all is a hard fail that tells servers to reject them. Use -all for stronger protection.
How do I know if my SPF record has too many lookups?
Use MXToolbox's SPF Record Lookup tool. It shows your total lookup count and flags any errors. Anything over 10 is in PermError territory.
Does SPF protect against email spoofing on its own?
No. SPF checks the envelope sender (MAIL FROM), not the visible From header that recipients see. An attacker can pass SPF while still displaying a different sender name. Full spoofing protection requires SPF, DKIM, and DMARC working together with alignment.