How to Fix Your SPF Record

TL;DR: Most SPF failures come from one of four causes — a missing or wrong include, exceeding the 10-lookup limit, having two SPF records in DNS, or using ~all (soft fail) instead of -all (hard fail). Run a free scan at kalenfy.com and we'll show you exactly which mechanism is failing and the record to replace it with.

What does an SPF failure actually mean?

When a receiving mail server checks your SPF record, it evaluates whether the sending IP is listed as an authorised sender. An SPF failure means one of three things:

• Fail / HardFail (-all) — the IP is explicitly not authorised. The receiving server can reject the message outright.
• SoftFail (~all) — the IP is "probably not" authorised. Most servers accept the message but mark it as suspicious, increasing spam likelihood.
• PermError — your record is structurally invalid (usually too many lookups or a syntax error). Servers treat this as a fail and may reject your mail entirely.
• TempError — a DNS lookup timed out during evaluation. Typically transient, but persistent TempErrors point to a resolver problem or an unreachable include target.

SPF failures mean your legitimate emails are more likely to land in spam — and your domain remains open to spoofing. DMARC can only enforce a p=reject policy if SPF (or DKIM) passes and is aligned. A broken SPF record undermines the whole authentication chain.

The four most common SPF failures

How to diagnose your SPF record

Before you fix anything, check what's actually in DNS. Open a terminal and run:

dig TXT yourdomain.com +short

Look for the line starting with v=spf1. If you see two such lines, you have duplicate records (fix #3 below). If you see none, you haven't published an SPF record at all. For a faster check, the Kalenfy scanner shows your parsed SPF record, counts your DNS lookups, flags each problem and gives you the corrected record to paste in.

Fix 1 — Wrong or missing include

Every service that sends email on behalf of your domain needs to be listed in your SPF record as an include: (or as an IP range with ip4:/ip6:). Common includes you may be missing:

Add missing includes to your existing record. Don't start a new v=spf1 line — that creates the duplicate problem (fix #3). A valid record looks like:

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

Check your provider's documentation for their exact SPF include string — these change occasionally as providers move infrastructure.

Fix 2 — Too many DNS lookups (PermError)

SPF has a hard limit of 10 DNS-resolving mechanisms (include, a, mx, ptr, exists) per record evaluation. Exceed it and you get a PermError — the receiving server stops evaluating and treats the result as a failure.

The fix is to either flatten lookups (replace includes with their underlying IP ranges, which don't count toward the limit) or remove includes for services you no longer use. See our detailed guide: how to fix SPF too many DNS lookups.

To count your current lookups quickly: run your domain through the Kalenfy scanner — it evaluates the full chain and shows the exact count and which includes are consuming the most.

Fix 3 — Multiple SPF records

You can only have one SPF record per domain. If DNS has two TXT records both starting with v=spf1, the RFC 7208 spec says the evaluation results in a PermError. This commonly happens when someone adds an SPF record for a new email service without realising one already exists.

The fix: log in to your DNS host, delete one of the two SPF records, and merge its include statements into the surviving record. Full walkthrough: how to fix multiple SPF records.

Fix 4 — Soft-fail instead of hard-fail

Many guides recommend ~all (soft fail) as a "safe" starting point. In practice, a soft-fail SPF record gives almost no protection — most mail servers accept ~all messages and just mark them as suspect. Spoofers are not blocked.

Once you're confident your SPF record authorises all your legitimate senders, change ~all to -all:

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

Combined with DMARC p=reject, -all tells receiving servers to discard messages from any IP not in your SPF record. See also: SPF softfail vs hardfail — which should you use?

Fix 5 — Syntax errors

SPF records must start with exactly v=spf1 (lowercase, no space before the 1) and end with an all mechanism (-all, ~all, ?all, or +all). Common syntax mistakes:

• Missing v=spf1 prefix entirely
• Space inside v=spf1 (e.g. v= spf1)
• Typo in an include domain (e.g. _spf.gogle.com)
• Using include: with a domain that has no SPF record of its own — this causes a PermError because the lookup fails
• Using ptr mechanism — deprecated; slow and unreliable, avoid it

After fixing: verify your SPF record

DNS changes can take a few minutes to propagate (sometimes up to an hour — see our guide on DNS propagation). Once propagated, verify the fix:

1. Run dig TXT yourdomain.com +short and confirm a single v=spf1 record ending in -all.
2. Send a test email to a Gmail or Outlook account and check the message headers for spf=pass.
3. Re-run the Kalenfy scanner — it shows the updated SPF result, lookup count, DKIM and DMARC status in one view.

Once SPF passes, check whether your DMARC policy is enforced (move from p=none to p=reject). SPF and DMARC work together — a passing SPF with a weak DMARC still leaves your domain spoofable.

FAQ

How do I know which include is causing my SPF to fail?

The easiest way is to run your domain through the Kalenfy scanner — it evaluates the full SPF chain and flags the specific mechanism causing the failure. Alternatively, check the bounce messages or mail headers from failed deliveries: the Received-SPF header usually names the IP that failed evaluation, which tells you which sender's include is missing.

Can I have SPF without DKIM?

Yes, SPF can pass independently of DKIM. But for DMARC to protect you, at least one of SPF or DKIM must pass and be aligned with the From header domain. If you have SPF but no DKIM and your mail is forwarded, the forwarded copy will likely fail SPF (the forwarding server's IP isn't in your record), DMARC will fail, and your mail may be rejected. Having both SPF and DKIM gives you redundancy.

Does an SPF record affect email deliverability?

Directly, yes. A missing or failing SPF record increases your spam score with most providers. A PermError (too many lookups or duplicate record) is treated as a hard failure and can cause outright rejection. A correctly published -all record, aligned with DMARC, is one of the strongest signals of a legitimate sender.

What is the maximum length of an SPF record?

A single TXT record in DNS must not exceed 255 characters per string (though most DNS implementations concatenate multiple strings in a single record transparently, up to about 450 characters total). If your SPF record approaches this limit, flattening or removing unused includes is the right fix — not adding more records.

How long does it take for an SPF fix to take effect?

Typically a few minutes to an hour, depending on your DNS provider's TTL setting and how recently resolvers cached your old record. If your TTL was set low (300 seconds or less) before you made the change, propagation is usually fast. Run a fresh dig query to confirm the new record is visible before re-testing delivery.