SPF Softfail Fix Guide (2026)

SPF softfail is the result when a receiving server evaluates your SPF record, finds that the sending IP is not in the authorized list, and the SPF record ends with ~all (the soft-fail mechanism). The receiving server then reports:

spf=softfail (google.com: domain of you@yourdomain.com does not designate 203.0.113.5 as permitted sender)

Softfail is not a pass. It's a "probably unauthorized, accept anyway but mark the message suspicious." Three consequences:

1. 1DMARC sees softfail as fail for alignment purposes. Your DMARC record either passes via DKIM alone or fails entirely. If DKIM is also broken or unaligned, DMARC fails, and Gmail / Microsoft route the message to spam.
2. 2Gmail penalizes softfail-only senders in reputation scoring, even when DMARC is satisfied via DKIM.
3. 3Some corporate filters treat softfail as hardfail. Exchange, Barracuda, and Proofpoint instances may reject softfail messages outright depending on tenant policy.

The fix is mechanical: figure out which sending IP or domain is missing from your SPF record and add it. The rest of this guide walks through the diagnostic and the five common causes. For the full SPF syntax reference, see spf-record-setup-cold-email.

Send a test from the affected mailbox to a personal Gmail account. Open > three dots > Show Original. Look for the Authentication-Results line:

spf=softfail (google.com: domain of user@yourdomain.com does not
     designate 203.0.113.5 as permitted sender)
     smtp.mailfrom=user@yourdomain.com

The three pieces of information you need:

Then check your current SPF record:

dig TXT yourdomain.com +short | grep spf1

Or use https://mxtoolbox.com/spf.aspx and enter your domain. Compare the IP from Show Original against the authorized senders in your SPF record. The missing IP is your fix target.

The exact text of the failure message contains the fix. If it says "does not designate 203.0.113.5", add that IP. If it says "does not designate mail.sequencer.com", add the sequencer's SPF include mechanism. Read it carefully before making changes.

Your SPF record ends with one of four mechanisms. The choice matters more than most cold emailers realize:

For cold email, use ~all. Hardfail is theoretically more secure, but a single missing ESP include causes 100% delivery failure. Softfail gives you the signal (softfail messages you'll catch in monitoring) without the risk of total delivery collapse.

The right mental model: SPF softfail is a symptom, not a problem. It's telling you "your record isn't complete." The fix is always to add the missing sender to the record, not to change ~all to +all. Changing to +all "makes the error go away" but also neuters SPF entirely.

Never change ~all to +all to suppress softfails. If you do, you'll stop seeing the softfail, but spoofers will also stop being blocked by SPF, and your domain becomes trivially impersonable.

The most common softfail cause: you added a new sending source (sequencer, ESP, monitoring tool) without adding its SPF include to your record.

The common SPF includes by sender type:

Combined SPF record example for Google Workspace + SmartLead:

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

Rules when editing:

1. 1Only one SPF record per domain. If you already have a TXT record starting with v=spf1, edit it, do not create a second one. Two records is an automatic SPF fail.
2. 2Start with v=spf1. No other prefix is valid.
3. 3End with ~all. Only one all mechanism, and it must be last.
4. 4Wait for DNS propagation. Changes take 15 minutes to 4 hours depending on your TTL. Re-test with Show Original after propagation.

Then re-send a test to Gmail and check Show Original again. SPF should now show pass instead of softfail. If it still shows softfail, move to Fix 2.

SPF records have a hard limit: no more than 10 DNS lookups during SPF evaluation. Each include: mechanism counts as 1 lookup and may trigger additional nested lookups inside the included record. Exceed 10 and the SPF evaluation returns permerror, which some receivers treat as softfail, and others treat as hardfail.

Common include lookup counts:

Example that exceeds the limit:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com
  include:sendgrid.net include:mailgun.org include:amazonses.com
  include:_spf.smartlead.ai include:_spf.apolloapi.io ~all

Total: 3+3+2+2+1+1+1 = 13 lookups. SPF evaluation fails with permerror, and every recipient may see softfail.

The fix when you're near or over the limit:

1. 1Remove unused includes. Audit which sending sources you actually use. Drop anything dormant.
2. 2Use ip4: directly for static IPs that don't change. ip4: counts as zero lookups. If your sequencer has a documented static IP range, listing those IPs directly saves lookups.
3. 3Flatten includes with a tool. Services like spf.transip.eu or dmarcly.com/tools/spf-flattener expand includes into literal IPs so you stay under 10 lookups. Warning: flattened records require regular updates because IP lists change.
4. 4Split sending across subdomains. Each subdomain has its own SPF record with its own 10-lookup budget. Move your transactional sends to mail.yourdomain.com and keep your cold email on yourdomain.com.

Verify with MXToolbox SPF record lookup: https://mxtoolbox.com/spf.aspx. The tool reports the lookup count explicitly. Target is <10, ideally <8 to leave headroom.

A second softfail cause: you have more than one TXT record starting with v=spf1. RFC 7208 section 4.5 is explicit. One SPF record per domain. Multiple records return a permerror, which receivers treat as softfail or fail.

How to check:

dig TXT yourdomain.com +short

Look for every line starting with v=spf1. If you see two or more, that's your problem.

Common causes of duplicate SPF records:

1. 1You added a new record instead of editing the existing one. When Sendgrid or your sequencer gave you an SPF record to add, you created a second TXT record next to the existing one.
2. 2Your DNS provider merged two records during a bulk import. Cloudflare, Route 53, and Namecheap sometimes store them as separate entries while they evaluate as multiple records.
3. 3Your registrar autocreated an SPF record when you set up a mailbox, and you manually added another later.

The fix:

1. 1Delete all existing TXT records starting with v=spf1.
2. 2Create a single new TXT record that includes all your authorized senders.
3. 3Verify with dig TXT yourdomain.com +short, should return exactly one line starting with v=spf1.
4. 4Wait 15-60 minutes for DNS propagation, then re-test with Gmail Show Original.

Cloudflare gotcha: Cloudflare stores the SPF record with neighboring TXT records (DMARC, verification tokens) all under the same hostname. That's fine, as long as only one of them starts with v=spf1. If you see two TXT records on the same hostname and both start with v=spf1, that's the duplicate.

Sequencer softfails are a special case. Your sequencer (Instantly, Apollo, Smartlead, Lemlist) may send through its own ESP infrastructure by default. In that case, the envelope sender is the sequencer's domain, not yours, so your SPF record isn't even being consulted.

What this looks like in headers:

spf=pass smtp.mailfrom=bounces@instantly-mail.net
header.from=you@yourdomain.com

SPF technically passes (on Instantly's domain), but DMARC alignment fails because the envelope sender domain (instantly-mail.net) doesn't match the visible From: (yourdomain.com). Receivers see this as functionally equivalent to softfail and may route to spam.

The fix, three options:

For cold email, option 1 is usually cleanest. Real Google Workspace or Microsoft 365 mailboxes (InboxKit at $2.99-3.50/mailbox/mo) remove the relay chain entirely. Option 2 is for setups that must use a relay ESP for volume reasons. Option 3 is a band-aid when you can't change the relay.

For the full DMARC alignment walkthrough, see dmarc-failed-gmail-fix and dkim-setup-cold-email.

After any SPF change, verify the fix with this 4-step test:

1. 1Wait for DNS propagation. Changes take 15 minutes to 4 hours. Check with dig TXT yourdomain.com +short, the new record should appear.
2. 2Lookup test with MXToolbox. Run the full SPF check at https://mxtoolbox.com/spf.aspx. Look for: - Single v=spf1 record ✓ - Total lookups < 10 ✓ - All expected includes present ✓ - Ends with ~all ✓
3. 3Send a test email to Gmail. Use a personal Gmail, not your own Workspace account (bias). Open > Show Original. Check for: - spf=pass (not softfail) - smtp.mailfrom=yourdomain.com (aligned with From:) - dmarc=pass
4. 4Check DMARC aggregate reports over 48 hours. If you have rua=mailto:... in your DMARC record, the reports will show whether other receivers (Yahoo, Microsoft 365) also see the fix. Use dmarcian, Postmark DMARC, or parsedmarc to read them.

If the softfail persists after the fix, the most likely cause is TTL. Your old SPF record is still cached at the receiving end. Wait 4-24 hours for the cache to expire, then re-test. DNS changes outlive the TTL in some recursive resolvers.

For continuous monitoring so softfails get caught before they damage reputation, see email-deliverability-monitoring-setup.

InboxKit's approach to SPF is automation + continuous monitoring:

Pricing: $39/mo for 10 slots on Professional, $99/mo for 30 slots on Agency, $299/mo for 100 slots on Enterprise. Azure tenants at $30/tenant for 100 M365 mailboxes.

For cold email setups running more than ~5 domains, manual SPF management is a significant time sink, editing records across multiple registrars, tracking lookup counts, and remembering to update when sequencer includes change. Automation is usually worth it once you pass that threshold. See dns-setup-guide for the broader DNS setup context.