SPF authentication failed

"SPF authentication failed" is the result a receiving mail server returns when it evaluates the Sender Policy Framework record for the message's envelope-sender domain and finds the connecting IP address is not authorized. It is one of the result codes defined by RFC 7208 and almost always shows up in the Authentication-Results and Received-SPF headers of the delivered (or bounced) message, e.g. spf=fail (sender IP is 203.0.113.5).

A key point most guides get wrong: SPF authenticates the SMTP envelope, not the visible From: address. Per RFC 7208 §2.3-§2.4, SPF checks the MAIL FROM (return-path / bounce address) and the HELO/EHLO hostname; §2.2 explicitly notes that checking other identities (like the visible From: header) against an SPF record is NOT RECOMMENDED. The address your recipients actually see in the From: header is never checked by SPF directly — that linkage only matters for DMARC (see below).

What causes "SPF authentication failed"?

There are five distinct causes, and the fix differs for each. Look at the SPF result word in the headers to tell them apart — RFC 7208 §2.6 defines fail, softfail, permerror, and temperror, and they do not mean the same thing:

• fail (hard fail, -all) — The sending IP is explicitly not authorized. The record exists, but this IP isn't in it. Most common when you start sending through a new provider/IP and forget to add it.
• softfail (~all) — A weak "probably not authorized" statement. Mail usually still delivers (often to spam) rather than bouncing. Frequently misreported as a hard "failure."
• permerror — The record can't be evaluated. The #1 real-world cause is exceeding the 10 DNS-lookup limit (RFC 7208 §4.6.4) by chaining too many include: mechanisms, or having a syntax error / more than one SPF TXT record on the domain.
• temperror — A transient DNS error during evaluation. Retry; if it persists, your DNS is intermittently failing to resolve.
• none — No SPF record was found at all. The domain has no v=spf1 TXT record.

How do I fix "SPF authentication failed"?

1. Identify the failing domain and result. Open the raw headers of a failed message and read the Received-SPF: / Authentication-Results: lines. Note the domain being checked (the MAIL FROM domain, which for relay services is often a subdomain) and the IP that failed.

2. Find your current record. SPF lives in a single DNS TXT record starting with v=spf1:

dig +short TXT yourdomain.com
# or
nslookup -type=TXT yourdomain.com

You must have exactly one v=spf1 record (RFC 7208 §3.2). If a domain publishes two or more, record selection produces a permerror per RFC 7208 §4.5.

3. Authorize every legitimate sender. Add an authorization mechanism for each service that sends as your domain. Use the provider's published include: rather than hardcoding IPs they may rotate:

v=spf1 include:sendgrid.net include:_spf.google.com ip4:203.0.113.5 -all

• include: pulls in a provider's SPF record (e.g. sendgrid.net for SendGrid/Twilio, amazonses.com for Amazon SES, _spf.google.com for Google Workspace).
• ip4: / ip6: authorize specific IPs you control.
• End with -all (hard fail) once you're confident, or ~all (softfail) while testing.

4. Stay under 10 DNS lookups. Each include, a, mx, ptr, exists, and redirect counts toward the limit of 10; more than 10 yields permerror and a failure (RFC 7208 §4.6.4). Also keep "void lookups" (NXDOMAIN/empty) to two or fewer. If you exceed the limit, remove unused services or use SPF flattening.

5. Wait for propagation and re-test. TXT changes can take up to the record's TTL to propagate. Validate with a checker such as MXToolbox or your provider's domain-authentication screen (SendGrid: Settings → Sender Authentication → Verify).

"SPF passes but DMARC still fails" — the alignment trap

If SPF reports pass but your mail is still rejected, the problem is DMARC alignment, not SPF itself. RFC 7489 requires the domain that passed SPF (the MAIL FROM domain) to align with the visible From: domain. Relay services like SendGrid, Amazon SES, and Courier set their own bounce/return-path domain by default, so SPF passes for their domain — which doesn't match yours, so DMARC fails.

The fix is to configure a custom return-path / MAIL FROM subdomain (a CNAME or MX the provider gives you, e.g. em.yourdomain.com or a custom MAIL FROM domain in Amazon SES). This makes the SPF-authenticated domain a subdomain of your From: domain, satisfying DMARC's relaxed SPF alignment. Alternatively, an aligned DKIM signature alone also satisfies DMARC even when SPF doesn't align.