How to Fix SPF Failures (softfail, hardfail, permerror)

SPF (Sender Policy Framework) tells receiving mail servers which IPs are authorized to send email for your domain. When SPF fails, your email is more likely to land in spam — or get rejected outright. Here’s how to diagnose which type of failure you have and fix it.

Step 1: Check Your Current SPF Record

Before fixing anything, see what you have. Run DomainScan’s SPF checker on your domain. It shows:

• Your current SPF record text
• Whether the syntax is valid
• The current DNS lookup count (critical — limit is 10)
• Which IPs are currently authorized
• Any detected issues

If you have no SPF record, skip to Setting Up SPF From Scratch.

Understanding SPF Failure Types

softfail (~all)

Email came from an IP not listed in your SPF record, but your record ends with ~all (softfail). This tells receivers: “this IP isn’t authorized, but don’t reject it.”

Result: Email is usually delivered but marked as suspicious. Gmail and other providers may use this to increase spam scores.

Diagnose: Find which IP is sending email that’s not in your record. Check your mail service’s documentation for the IPs or SPF include: value to add.

fail (hardfail, -all)

Email came from an IP not listed, and your record ends with -all (hardfail). This tells receivers: “reject email from unauthorized IPs.”

Result: Email is rejected or bounced. The sender receives an NDR (Non-Delivery Report).

This is correct behavior if the IP genuinely isn’t authorized. If legitimate email is being rejected, you’re missing a sending source in your SPF record.

permerror (permanent error)

The SPF record has a syntax error or exceeds the 10 DNS lookup limit. Receivers treat this as if there’s no SPF record, and some treat it as a fail.

Common causes:

• More than 10 DNS lookups (most common)
• Duplicate v=spf1 prefix
• Invalid mechanism syntax
• Circular include: references

temperror (temporary error)

A DNS lookup failed during SPF evaluation — usually a transient network issue on the receiver’s side. Most receivers retry before classifying this as a failure. If you see this consistently, your DNS provider may have reliability issues.

none

No SPF record exists at your domain. Many mail providers treat this as suspicious for established domains.

Fixing the 10 DNS Lookup Limit (permerror / softfail)

This is the most common SPF issue. Every include:, a:, mx:, and ptr: mechanism that requires a DNS lookup counts toward the limit. ip4: and ip6: mechanisms (hardcoded IPs) don’t count.

Check your current count with DomainScan’s SPF checker — it shows the exact lookup count per mechanism.

Example: A record with too many lookups

v=spf1 include:_spf.google.com include:mailgun.org include:servers.mcsv.net 
include:spf.protection.outlook.com include:sendgrid.net include:amazonses.com 
include:_spf.salesforce.com include:helpscout.net include:spf.mandrillapp.com 
include:spf.postmarkapp.com -all

This has 10 include: directives — but each one may expand into multiple additional lookups, pushing the total over 10 easily.

Solution: SPF Flattening

Replace dynamic include: mechanisms with hardcoded ip4: and ip6: lists:

1. Run DomainScan’s SPF checker and note all IP ranges authorized by each include:
2. Look up each service’s current IP ranges (check their documentation)
3. Replace include:service.com with ip4:203.0.113.0/24 ip4:198.51.100.0/24 (their actual IPs)
4. Use a subdomain SPF record for some services (if they support it)

Downside of flattening: If a service changes their IP ranges, your SPF won’t automatically update. You’ll need to manually update. Set a calendar reminder to review quarterly.

Alternative: SPF Macros / Subdomains

Some providers let you redirect part of your SPF evaluation to a subdomain:

v=spf1 include:spf.yourdomain.com -all

This keeps the root record simple while the subdomain record contains the detail. Moving between providers only requires updating the subdomain record.

Fixing Missing Sending Sources (softfail / fail)

If SPF is failing for a legitimate service, add their SPF include: value to your record.

Common Services and Their SPF Values

Find the correct value in the service’s email authentication documentation, or ask their support.

Fixing Multiple SPF Records

You must have exactly one TXT record at your root domain beginning with v=spf1. If you have two, receiving servers see conflicting records and may treat SPF as permerror.

Check: Query TXT records with DomainScan’s DNS tool and look for multiple v=spf1 entries.

Fix: Delete all but one. Merge all include: directives and IP ranges into a single record.

# WRONG — two separate records
"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:sendgrid.net ~all"

# RIGHT — one merged record
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Setting Up SPF From Scratch

If you have no SPF record, create one as a TXT record at your root domain (@):

Step 1: Identify all email sending sources

List every service that sends email using your domain:

• Your main mail provider (Google Workspace, Microsoft 365, etc.)
• Transactional email (SendGrid, Postmark, Mailgun, SES)
• Marketing email (Mailchimp, HubSpot, Klaviyo)
• CRM and support tools (Salesforce, Zendesk, Intercom)
• Your own mail server (if applicable)

Step 2: Build the record

v=spf1 [mechanisms] [all]

Start with ~all (softfail) to avoid accidental rejection while testing:

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

Step 3: Validate

Run DomainScan’s SPF checker to confirm:

• Syntax is valid
• DNS lookup count is under 10
• All known sending IPs are covered

Step 4: Monitor, then switch to -all

After one week of ~all and no unexpected failures, switch to -all for stronger enforcement.

The Correct SPF Record Structure

v=spf1 [ip4/ip6 mechanisms] [include mechanisms] [all mechanism]

• Put ip4: and ip6: mechanisms first (no lookups, faster evaluation)
• Then include: mechanisms
• Always end with either ~all or -all (never +all, which authorizes everything)
• Use -all for maximum enforcement once you’ve verified all senders are listed

After fixing SPF, add DMARC to enforce the policy and get reports on failures. SPF alone without DMARC provides limited protection.