Mailybox
check dmarcdiagnose a bounce
Home / Email errors / generic
generic error

SPF Softfail — Received-SPF: softfail

The sending IP is not authorized by the domain’s SPF record, and the record ends in ~all, so receivers are asked to accept but mark the message rather than reject it.

Diagnose your exact bounce SPF Dependency Graph

What the bounce says

Exact wording as it appears in the rejection or NDR. Placeholders such as x.x.x.x and example.com stand for your own address and domain.

Received-SPF: softfail (google.com: domain of transitioning user@example.com does not designate x.x.x.x as permitted sender)

spf=softfail (sender IP is x.x.x.x) smtp.mailfrom=example.com

Authentication-Results: spf=softfail

Softfail means the sending IP is not authorized by the domain’s SPF record, and the record ends in ~all, which asks receivers to accept the message but treat it with suspicion. It is a signal, not a rejection — until DMARC turns it into one.

Reviewed 2026-09-08. Provider wording and requirements change; the provider reference below is authoritative.

Most common causes

  • A sending platform or server is missing from the SPF record
  • The envelope sender domain is not the one you expected
  • Forwarding changed the connecting IP
  • The record was recently changed and caches still serve the old one

What to verify next

  1. Read Received-SPF or Authentication-Results for the evaluated identity and IP
  2. Add the missing source to SPF and check the lookup budget
  3. Confirm DKIM aligns so DMARC still passes despite the SPF softfail
  4. Retest after the TTL elapses

What softfail tells a receiver

The domain owner has listed authorized senders and marked everything else as "probably not us" rather than "definitely not us". Receivers add weight to spam scoring and, under DMARC, count SPF as failed. Nothing is delivered differently by SPF alone.

The evaluated identity is the envelope sender. A softfail for a platform bounce domain is the platform’s problem; a softfail for your domain means a source is missing from your record.

  • ~all: accept but mark.
  • SPF fails for DMARC purposes.
  • Identity evaluated is MAIL FROM, not From.

Find the missing source

Read the Received-SPF or Authentication-Results header: it names the IP and the domain evaluated. Compare the IP with the sources in your record using the dependency graph. Add the platform or range, check the lookup budget, and publish.

Why DKIM matters here

Forwarding breaks SPF for everyone, so a domain relying on SPF alone sees softfails on legitimate forwarded mail. An aligned DKIM signature keeps DMARC passing when SPF softfails; configure both.

Best diagnostic path

Live analysis

Mail Failure Doctor

Classify the complete rejection and preserve provider-specific diagnostic context.

Open analysis → Live analysis

SPF Dependency Graph

Resolve recursive authorization paths, lookup pressure and the effective sender policy.

Open analysis → Live analysis

Email Header Forensics

Inspect From, Sender, Reply-To, Return-Path and transport evidence in the raw message.

Open analysis →

Known limits

  • Receivers weigh softfail differently; some ignore it, some score it heavily.
  • Historical headers reflect DNS at delivery time.

Common questions

Should I change ~all to -all?

Only after every legitimate sender is listed. -all makes the same gap a hard fail.

Why softfail when my SPF is correct?

The message probably used a different envelope domain — a platform bounce domain — or was forwarded.

Does softfail cause bounces?

Not by itself. Combined with DMARC enforcement or a strict receiver, it can.

Why the exact message matters

The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.

Provider reference

For the provider-defined meaning and current requirements, review RFC 7208 §8.5 — Softfail.