Common SPF Errors: Understanding and Fixing SPF Failures

SPF errors can silently undermine your email deliverability. Understanding what each error means—and how to fix it—helps you maintain reliable email authentication.

SPF Result Codes Explained

When an email server evaluates your SPF record, it returns one of seven possible results. Each has different implications for email delivery.

Pass

The sending IP address is authorized by your SPF record. This is the result you want.

spf=pass (domain.com: 192.0.2.1 is permitted)

What it means: The email came from a server you've explicitly authorized. Receiving servers treat this as a positive authentication signal.

Fail (HardFail)

The sending IP address is explicitly not authorized, and your SPF record uses -all.

spf=fail (domain.com: 192.0.2.1 is not permitted)

What it means: Your SPF record specifically says this IP should not send email for your domain. Many servers will reject the email or send it to spam.

Common causes:

• Email sent from a service not in your SPF record
• Forwarded email that lost its original authentication
• Spoofed email (which is the intended result—SPF doing its job)

SoftFail

The sending IP isn't authorized, but your SPF record uses ~all instead of -all.

spf=softfail (domain.com: 192.0.2.1 is not permitted)

What it means: The IP probably shouldn't be sending email for your domain, but you're not certain enough to hard fail. Receiving servers treat this with suspicion but typically don't reject outright.

When it happens:

• You're using ~all during SPF setup while testing
• A legitimate service isn't in your SPF record yet
• Email forwarding scenarios

Neutral

Your SPF record uses ?all or specifically matches with a ? qualifier.

spf=neutral (domain.com: 192.0.2.1 is neither permitted nor denied)

What it means: Your SPF record makes no statement about whether this IP is authorized. It's treated similarly to having no SPF record.

Why it's rarely used: Neutral doesn't help with authentication. Most organizations use ~all or -all instead.

None

No SPF record exists for the domain.

spf=none (domain.com: no SPF record found)

What it means: The domain hasn't published an SPF record. Email servers can't verify whether the sending IP is authorized.

How to fix: Create an SPF record for your domain. Even if you don't send email from a domain, publish v=spf1 -all to indicate no servers are authorized.

TempError

A temporary error occurred during SPF evaluation, usually a DNS timeout or server unavailability.

spf=temperror (temporary DNS error)

What it means: Something went wrong during the lookup, but it might work if tried again. Most servers will retry or accept the email tentatively.

Common causes:

• DNS server temporarily unavailable
• Network issues
• DNS rate limiting

Usually resolves on its own. If persistent, check your DNS provider's status.

PermError

A permanent error in your SPF record makes it impossible to evaluate.

spf=permerror (domain.com: SPF record has syntax error)

What it means: Your SPF record is broken. This is the most serious SPF error because it typically results in authentication failure.

Common causes:

• Syntax errors in your SPF record
• More than 10 DNS lookups
• Multiple SPF records for the same domain
• Infinite loops in includes

Diagnosing SPF Problems

When your emails fail SPF, start by checking your current SPF record.

Check email headers

Email headers contain the SPF evaluation result. In Gmail, open a message and click the three dots → "Show original." Look for the Authentication-Results header:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of sender@domain.com designates 192.0.2.1 as permitted sender)

This tells you:

• The SPF result (pass, fail, softfail, etc.)
• The IP address that sent the email
• Why the result occurred

Verify the sending IP

If SPF is failing, identify which IP address is sending and verify it should be authorized. Your email service's documentation usually lists their sending IPs or include statements.

Count DNS lookups

If you're getting PermError, count your DNS lookups. Each include, a, mx, and redirect counts toward the limit of 10. See our guide on the SPF 10 DNS lookup limit.

Common SPF Misconfigurations

Multiple SPF records

The problem: Having two TXT records that both start with v=spf1.

Wrong:

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

Correct:

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

How to fix: Combine all authorized sources into a single SPF record.

Missing email services

The problem: A legitimate email service isn't in your SPF record.

Symptoms: Emails from that service get softfail or fail results.

How to fix: Add the service's include statement or IP addresses to your SPF record. Check the service's documentation for the correct SPF configuration.

Typos in include domains

The problem: Misspelled include domains cause lookup failures.

Wrong:

v=spf1 include:_spf.gogole.com ~all

Correct:

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

How to fix: Double-check include domain names against official documentation.

Using deprecated SPF record type

The problem: Using the old SPF DNS record type (type 99) instead of TXT.

Background: The dedicated SPF record type was deprecated in 2014. Some old configurations still use it.

How to fix: Publish your SPF record as a TXT record only. Remove any type-99 SPF records.

Incorrect CIDR notation

The problem: Invalid IP ranges in ip4 or ip6 mechanisms.

Wrong:

v=spf1 ip4:192.0.2.0/33 ~all

Correct:

v=spf1 ip4:192.0.2.0/24 ~all

How to fix: Verify CIDR notation is valid. For IPv4, the number after the slash must be between 0 and 32.

Missing the all mechanism

The problem: SPF record doesn't specify what to do with non-matching IPs.

Incomplete:

v=spf1 include:_spf.google.com

Complete:

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

How to fix: Always end your SPF record with -all, ~all, or ?all.

SoftFail vs HardFail: When Does It Matter?

The difference between ~all (softfail) and -all (hardfail) affects how receiving servers handle unauthorized emails.

Use ~all (softfail) when:

• You're setting up SPF for the first time
• You're not 100% sure you've listed all legitimate senders
• You use email forwarding extensively
• You want to monitor before enforcing

Use -all (hardfail) when:

• You're confident your SPF record is complete
• You want maximum protection against spoofing
• You have DMARC with a reject policy (recommended pairing)

Practical recommendation: Start with ~all while setting up and testing. Once you're confident and have monitored for issues, move to -all for stronger protection.

Fixing PermError

PermError requires immediate attention. Here's a systematic approach:

1. Check for multiple SPF records. Query your DNS for TXT records and ensure only one starts with v=spf1.

2. Count DNS lookups. Use a checker tool to count total lookups. If over 10, you need to optimize.

3. Validate syntax. Look for typos, invalid mechanisms, or malformed entries.

4. Check for loops. Ensure your includes don't create circular references.

5. Verify mechanism order. While order rarely causes errors, ensure all is at the end.

If you need help generating a valid SPF record, SPF Creator can build one based on your email services.

When SPF Passes But Email Still Goes to Spam

SPF pass is a positive signal, but it's not the only factor in email delivery.

Other factors that matter:

• DKIM authentication
• DMARC policy
• Sender reputation
• Email content and formatting
• Recipient engagement history
• List quality and acquisition practices

If SPF is passing but deliverability is poor, investigate these other areas.

Monitor Your SPF Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.