EmailPosture

SPF Record Not Working? Common Causes and Fixes

A troubleshooting guide. Email Posture.

SPF looks simple, one TXT record listing who can send mail for your domain, but it breaks in a few specific, predictable ways. If your mail is failing SPF or your checker is flagging it, you're almost certainly hitting one of the issues below. Here they are, roughly in order of how often they're the culprit, with the fix for each. Check your domain first so you know which one you're dealing with.

1. You have two SPF records

A domain may publish exactly one SPF record. If you have two TXT records that both start with v=spf1 (a common result of adding a new sender without removing the old line), SPF returns a permanent error and every receiver treats it as broken. Fix: merge them into a single record with all the mechanisms on one line.

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

2. Too many DNS lookups (the 10-lookup limit)

This is the sneaky one. SPF allows a maximum of ten DNS lookups while it evaluates your record, and every include: counts, plus any lookups those includes trigger. Stack up enough providers and you blow past ten, which causes a permerror, and SPF silently fails even though the record looks fine. Fix: remove senders you no longer use, and if you're still over the limit, "flatten" heavy includes (replace an include with the specific IP ranges) or use an SPF management service that keeps you under ten.

3. A sender is missing from the record

If a tool sends mail as your domain but isn't listed in SPF, that mail fails. The usual suspects are services added after the record was first written: a new CRM, a help desk, an invoicing app, a marketing platform. Fix: list every sender. Each provider documents the include: or IP you need to add.

4. Syntax mistakes

SPF is picky. Common errors: a missing v=spf1 at the start, stray spaces, the wrong mechanism, or more than one "all" term. Keep it to one clean line, start with v=spf1, and end with a single all mechanism.

5. Using +all (this allows the whole internet)

Ending your record with +all tells receivers that any server may send as you, which defeats the entire point. Use -all (hard fail) once you're confident your sender list is complete, or ~all (soft fail) while you're still verifying. Never +all.

6. Published on the wrong host

SPF belongs as a TXT record on the domain that appears in the envelope sender, normally your root domain (host @). If it's on a subdomain that doesn't send, or stored as the wrong record type, receivers won't find it. Fix: publish the TXT record at the root, or at the exact sending subdomain if that's what you use.

7. SPF passes but DMARC still fails (alignment and forwarding)

Two subtle ones. First, for SPF to satisfy DMARC it must "align," meaning the envelope-from domain matches your visible From domain; some sending services use their own envelope domain, so SPF passes for them but doesn't align for you. That's exactly why you also want DKIM. Second, forwarding breaks SPF: when a message is forwarded, the sending server changes, so SPF fails at the destination. DKIM survives forwarding, which is another reason not to rely on SPF alone.

How to check your work

After any change, give DNS a few minutes, then re-run the checker. It reports whether SPF is present, well-formed, within the lookup limit, and ending in a sensible policy, and it does the same for DKIM and DMARC so you can see the whole picture.

See exactly what's wrong with your SPF (and DKIM, DMARC, DNSSEC) in ten seconds.

Check your domain free
© 2026 Email PostureAboutPricingResourcesFAQSecurityHow We GradeTermsPrivacyContact