How to Fix SPF Record Errors: A Step-by-Step Guide

The silent failure behind "missing" emails

Your payment reminders went out on the first of the month. A week later, three clients say they never got them, and there they are in spam. Nothing in the email was suspicious. The problem was in your DNS: a broken SPF record telling Gmail and Outlook not to trust your domain.

SPF errors are common because the record looks simple, gets edited by different people over the years, and fails silently. This guide covers the mistakes we see most often, each with a broken and a fixed example.

SPF in two sentences

SPF (Sender Policy Framework) is a TXT record in your DNS that lists which servers may send email for your domain. Receiving servers check the sender's IP against that list and record pass, fail, softfail, neutral or error.

One detail explains half of all SPF confusion: SPF is checked against the Return-Path (envelope sender) domain, not the From address your recipient sees.

Step 1: See what you actually have

Before changing anything, run your domain through our free SPF record checker. It shows the record, every mechanism, how many of the 10 allowed DNS lookups you use, and warnings for the problems below. From a terminal, dig TXT example.com +short lists every TXT record.

Then run the domain health check. It tests SPF, DKIM, DMARC, MX and blacklists in one go, so you'll know whether SPF is your only problem.

The 8 most common SPF errors and how to fix them

Below, example.com is your domain and names like _spf.crm-example.com are placeholders for your tools. Use the values from each provider's setup docs.

1. Two SPF records on one domain

A new tool's guide says "add this TXT record" and someone adds it next to the old one. A domain may have exactly one record starting with v=spf1. With two, receivers return a PermError, which many treat as a failure.

• Broken: v=spf1 include:_spf.google.com ~all plus a second record v=spf1 include:_spf.crm-example.com ~all
• Fixed: v=spf1 include:_spf.google.com include:_spf.crm-example.com ~all

Merge the mechanisms into one record and delete the other. Other TXT records, such as verification codes, are fine.

2. More than 10 DNS lookups (PermError)

Every include, a, mx, ptr, exists and redirect costs a DNS lookup, and so does everything nested inside an include. The limit is 10. Go one over and SPF returns PermError for every message. ip4, ip6 and all are free.

• Broken: v=spf1 a mx include:_spf.google.com include:spf.protection.outlook.com include:_spf.crm-example.com include:mail.helpdesk-example.com include:servers.old-mailer.net ~all
• Fixed: v=spf1 ip4:203.0.113.10 include:_spf.google.com include:_spf.crm-example.com ~all

To get back under 10, remove tools you no longer use, drop a and mx unless those servers really send mail (list their IP with ip4: instead), and consider moving automated sending to a subdomain with its own record and its own 10-lookup budget. Be careful with "flattening" includes into raw IPs: it works until the provider changes its IPs.

3. Missing include for a sending service

Your record covers Google Workspace, but your invoicing tool also sends as @example.com and isn't listed. Only those emails fail, which makes this hard to spot.

• Broken: v=spf1 include:_spf.google.com ~all
• Fixed: v=spf1 include:_spf.google.com include:_spf.invoicing-example.com ~all

List everything that sends as your domain: mailbox, CRM, helpdesk, invoicing, contact forms, email platform. Then check each provider's docs. Many use their own or a custom Return-Path and need a CNAME or DKIM record instead of an include, so an include would only waste lookups.

4. ~all vs -all vs ?all: the wrong ending

• -all (fail): unlisted servers are not allowed. Strictest.
• ~all (softfail): unlisted servers are suspicious. The most common choice.
• ?all (neutral): no opinion, which protects about as much as no record at all.

• Broken: v=spf1 include:_spf.google.com ?all
• Fixed: v=spf1 include:_spf.google.com ~all

Use ~all while you're confirming every sender, and -all once the list is complete. With DMARC enforced, DMARC does most of the policy work, so many well-run domains keep ~all.

5. +all: the setting that makes SPF pointless

+all means "any server on the internet may send as this domain". It's sometimes added as a quick fix when legitimate mail fails. It also invites spoofing, and spam filters know it.

• Broken: v=spf1 +all
• Fixed: v=spf1 include:_spf.google.com include:_spf.crm-example.com ~all

Replace it today, then find the sender that was failing (usually error #3).

6. Syntax typos

SPF parsers are strict. One wrong character can invalidate the record or silently skip a mechanism.

• Broken: v=spf1 ipv4:203.0.113.10 include: _spf.google.com ~all include:_spf.crm-example.com
• Fixed: v=spf1 ip4:203.0.113.10 include:_spf.google.com include:_spf.crm-example.com ~all

Watch for ipv4: instead of ip4:, a space after the colon, mechanisms after all (ignored), curly quotes pasted from Word, and invalid ranges like /33.

7. Records that are too long

A single string in a TXT record holds at most 255 characters. Longer ones get rejected by your DNS panel or published broken.

• Broken: one 300-character string listing twenty separate ip4: addresses
• Fixed: v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/26 include:_spf.google.com ~all

Use CIDR ranges instead of single IPs. If it's still long, split it into quoted strings in the same TXT record: "v=spf1 ip4:203.0.113.0/24 " "include:_spf.google.com ~all". Strings are joined with no separator, so keep the trailing space.

8. Forgetting subdomains

SPF isn't inherited. A record on example.com does nothing for billing.example.com.

• Broken: SPF only on example.com, while reminders use billing.example.com as the envelope sender
• Fixed: on billing.example.com: v=spf1 include:_spf.invoicing-example.com ~all

Domains that never send email (old brands, parked domains) should publish v=spf1 -all so spammers can't borrow them.

After the fix: a quick checklist

1. Exactly one TXT record starts with v=spf1.
2. The SPF checker shows 10 lookups or fewer, with some spare.
3. Every service sending as your domain is included or covered by its own Return-Path.
4. The record ends in ~all or -all.
5. Sending subdomains have their own records.

Then send a test to a Gmail address, open "Show original" and look for SPF: PASS.

SPF alone isn't enough

SPF doesn't check the From address people see, and it often breaks when mail is forwarded. That's why Gmail and Yahoo have required bulk senders to use SPF, DKIM and DMARC since February 2024. Next, work through the common DKIM setup errors, then move DMARC from p=none to p=reject.

How MailerBit helps

MailerBit requires you to verify your own domain before you send a campaign. Domain settings show the exact DNS records to add (a DKIM key and a custom Return-Path CNAME) with copy buttons, and one click on Check Verification confirms them once they're live.

The custom Return-Path routes bounces through your own domain, and SPF is evaluated on that Return-Path subdomain, so setup doesn't add an include to your main SPF record or use up your lookup budget. Mail is signed with your own domain, so you build your own domain reputation; new domains get an automatic warm-up, and accounts with bounce rates above 5% or complaint rates above 0.1% are paused automatically. The SPF, DKIM, DMARC, MX, blacklist and domain health checkers are free, no account needed.

If your payment reminders and client statements keep landing in spam, fix SPF first. Then start your 7-day free MailerBit trial, verify your domain, and send each client their own amounts and due dates from an authenticated domain.