SPF Fail, Softfail, and Hardfail Explained

Email Authentication

SPF (Sender Policy Framework) checks whether the server sending an email is authorized to send for that domain. When SPF fails, it means the sending server wasn't listed as an authorized sender. But not all failures are the same — the type of failure affects how receiving servers treat your email.

SPF Result Types

When a mail server checks SPF, it returns one of these results:

Understanding Fail vs Softfail

The difference comes from how your SPF record ends:

Hardfail (-all)

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

The -all says: "Reject anything not explicitly authorized." Unauthorized servers get a fail result.

When to use: You know all your legitimate sending sources and want strict enforcement.

Softfail (~all)

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

The ~all says: "Unauthorized servers are suspicious, but don't outright reject." Unauthorized servers get a softfail result.

When to use: You're still identifying all sending sources, or you have forwarding scenarios.

Neutral (?all)

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

The ?all says: "I make no statement about unauthorized servers." Unauthorized servers get a neutral result.

When to use: Rarely — this essentially disables SPF for unlisted senders.

Why SPF Fails

1. Sending Server Not in SPF Record

The most common cause. You're sending email through a server or service that isn't authorized in your SPF record.

Example: You set up SendGrid for transactional email but forgot to add it to SPF:

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

SendGrid emails fail because sendgrid.net isn't included.

Fix:

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

2. Email Forwarding

When email is forwarded, the forwarding server sends it — not your original server. That forwarding server isn't in your SPF record.

You → send from mail.company.com (authorized)
Recipient → forwards to personal@gmail.com
Forwarding server → sends to Gmail (NOT authorized for company.com)
Gmail → SPF fail for company.com

Solutions:

• Rely on DKIM (survives forwarding if message isn't modified)
• Use services that support SRS (Sender Rewriting Scheme)
• Accept some forwarding failures

3. Incomplete SPF Record

You've listed some sending sources but missed others:

• Marketing platform
• CRM system
• Support ticketing
• Internal applications
• Development/staging environments

Fix: Audit all systems that send email from your domain.

4. Too Many DNS Lookups

SPF has a 10 DNS lookup limit. If your record exceeds this, you get permerror:

v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com include:servers.mcsv.net include:mail.zendesk.com include:spf.mandrillapp.com ...

Each include and certain other mechanisms count as lookups. Nested includes also count.

Solutions:

• Remove unused includes
• Flatten your SPF record (replace includes with direct IP ranges)
• Use an SPF management service

5. DNS Propagation Issues

After updating your SPF record, DNS changes take time to propagate. During this window, some servers see the old record.

Fix: Wait 24-48 hours for full propagation, or lower TTL before making changes.

Diagnosing SPF Failures

Check Your SPF Record

Use SPF Record Check to:

• Verify your record syntax
• Count DNS lookups
• See all authorized IP ranges
• Identify errors

Examine Email Headers

Failed emails contain authentication results:

Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of sender@company.com
       does not designate 192.0.2.50 as permitted sender)
       smtp.mailfrom=sender@company.com

This tells you:

• Result: softfail
• The unauthorized IP: 192.0.2.50
• What the server was checking: company.com

Identify the Sending IP

Once you know the IP that failed, determine what sent from it:

• Check if it's a known service (look up the IP)
• Check if it's your own server
• Check if it's a forwarding service

Fixing SPF Failures

Step 1: Audit Sending Sources

List everything that sends email as your domain:

Step 2: Update Your SPF Record

Combine all legitimate senders:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:mail.zendesk.com ~all

Step 3: Verify Lookup Count

Count your DNS lookups (must be 10 or fewer):

• Each include: = 1+ lookups
• Each a: = 1 lookup
• Each mx: = 1 lookup
• Each redirect: = 1 lookup
• ip4: and ip6: = 0 lookups

Step 4: Test Before Enforcing

If moving from ~all to -all:

1. Monitor delivery rates
2. Check DMARC reports for failures
3. Verify all sources are authenticated
4. Then switch to -all

SPF and DMARC

SPF alone has limitations. When combined with DMARC:

• SPF alignment matters (not just SPF pass)
• DMARC policy determines what happens on failure
• DKIM provides backup authentication

With p=reject DMARC policy:

• SPF softfail + DKIM fail = rejected
• SPF fail + DKIM fail = rejected
• SPF pass (aligned) OR DKIM pass (aligned) = delivered

Common SPF Include Statements

Related Articles

---

Monitor SPF Automatically

The Email Deliverability Suite monitors your SPF record, DKIM, DMARC, MX records and blacklist status daily. Get alerts when your SPF changes or breaks — before your emails start failing.