SPF Validation Error: What Each Message Means and How to Fix It

How SPF is evaluated, briefly

A receiving server takes the domain in the envelope sender (the Return-Path), fetches its TXT record that starts with v=spf1, and walks through it left to right: ip4:, ip6:, a, mx, include:, exists:, then the all at the end. The result is pass, fail, softfail, neutral, none, TempError or PermError.

The important part: a PermError isn't a partial failure. The receiver can't evaluate your record at all, so no message gets an SPF pass. If DKIM is also missing or misaligned, DMARC fails too. Check your record with the SPF checker.

The errors, one by one

Checker message	What it means	Fix
Multiple SPF records	Two or more TXT records start with v=spf1	Merge into one
Too many DNS lookups / exceeds 10	Nested includes need more than 10 lookups	Remove or restructure includes
Invalid syntax / unknown mechanism	A typo or a non-SPF token	Correct the token
Include has no SPF record	An include: target returns nothing	Fix or remove the include
Void lookups exceeded	More than 2 lookups returned nothing	Remove dead includes and a/mx on empty names
Record too long / string over 255 chars	One TXT string exceeds 255 characters	Split into quoted strings, or shorten
+all used	Anyone may send as you	Change to ~all or -all
No SPF record	Nothing published	Publish one with the SPF generator

Multiple SPF records

This is the most frequent one. A new tool's setup guide says "add this SPF record", and someone adds a second TXT row instead of editing the first. RFC 7208 is clear: more than one v=spf1 record is a PermError.

Combine them. Take the mechanisms from both and put them in one record:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

The SPF record merger does this from two pasted records, and combining services into one SPF record walks through the usual pairs. Other TXT records on the domain (site verification, DKIM on its own selector name) are fine; only records starting v=spf1 count.

Too many DNS lookups

SPF allows at most 10 mechanisms that need a DNS lookup: include, a, mx, exists, ptr and redirect. Lookups inside nested includes count. A record with five includes can easily exceed 10 because each provider's include pulls in more includes. ip4: and ip6: don't count.

Count yours with the SPF lookup counter. To get under the limit, in order of preference:

1. Remove includes for services you no longer use. This is usually most of the fix.
2. Drop a and mx if those hosts don't send mail.
3. Move a sender to a subdomain with its own SPF (common for marketing and transactional mail).
4. Flatten as a last resort with the SPF flattener, and recheck it regularly, because providers change their IPs.

The longer explanation is in SPF too many DNS lookups.

Syntax mistakes

Things checkers commonly catch:

• include without a colon, or with a space: include: sendgrid.net
• ip4: with a hostname instead of an address, or a malformed CIDR range
• smart quotes pasted from a document
• the v=spf1 tag not at the start, or written v=spf2
• anything after all, which is ignored and usually signals a mistake

Includes that point nowhere

If you include: a domain that has no SPF record (an old vendor, a typo), evaluation fails. Look up each include target on its own. Remove dead ones.

SPF passes but DMARC still fails

SPF can pass and still not help DMARC. DMARC needs SPF to pass and align: the Return-Path domain must match your From domain. Many third-party senders use their own bounce domain, so SPF passes for them, not for you. The fix there is DKIM signing on your domain, or a custom return-path where the provider supports it. See what is DMARC alignment and the DMARC checker.

A quick repair routine

1. List every TXT record on the root domain. Delete all but one v=spf1 record after merging.
2. List every service that sends as your domain. Remove includes for any that don't.
3. Count lookups. Get to 10 or fewer.
4. End with ~all (with DMARC) or -all.
5. Re-check from a public resolver after the TTL passes.
6. Send a test to a mailbox you control and read the Authentication-Results header with the email header analyzer.

After SPF: check the list

A broken SPF record makes good mail look forged. A fixed one removes that problem, and leaves the other big signal receivers watch: how many of your messages hit addresses that don't exist. Teams often discover their SPF error after a campaign goes badly, fix the DNS, then resend to the same list and wonder why results don't recover. If the list has dead mailboxes, the domain keeps paying for them.

Run the list through the verify page before the next send. Each address gets a live mailbox check; invalid ones are marked for removal, and catch-all addresses come back as risky, never guessed valid. For many sending domains at once, the bulk email authentication checker reads SPF, DKIM and DMARC together.

What it costs

• Pro, $39 a month: Unlimited email verification.*
• Starter, $9 a month: 2,500 emails a month.
• Free: the first 100 checks with a Google sign-in, no card.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.

The SPF checker, lookup counter, merger and flattener are free and need no sign-up. See pricing.

More reading: SPF, DKIM and DMARC explained, common SPF mistakes in 696 company domains.