Guides

SPF softfail: what it means, and when to change ~all

Last updated 2026-09-28

You've found spf=softfail in a header or a report. The server that delivered the message isn't in your SPF record, and the record ends in ~all. The fix depends on whether that server is yours.

Is softfail a failure? For DMARC, yes: only a pass counts. For a receiver reading SPF on its own, it's a hint. RFC 7208 says receivers should not reject a message on a softfail alone.

1. Find the server and the domain that were checked. In the received message, read the Authentication-Results header. The IP sits beside spf=softfail and the checked domain follows smtp.mailfrom=. In a DMARC report, read source_ip and the SPF domain under auth_results.
2. Decide whether the server is yours. Look the IP up, or match it against the platforms you send from. A helpdesk, an invoice app or a marketing tool each has its own servers.
3. If it's yours, add it to the record. Use the include your platform documents. Our provider setup pages hold the include for each one. Publish it, then count the lookups.
4. If it isn't yours, leave the record alone. The softfail is what the record is for. Check the DKIM result on the same message instead, because DMARC can still pass.

Softfail is one of four endings

The last term of an SPF record sets the result for a server the record didn't list. Each ending pairs a qualifier with all, and RFC 7208 maps each qualifier to a result.

A server the record does list passes under any ending. The ending only matters for the ones you left out.

What receivers do with a softfail

The standard leaves the decision to the receiver. RFC 7208 says receiving software should not reject the message based solely on a softfail, but may subject it to closer scrutiny. In practice the result feeds the spam filter as one signal among many.

DMARC is stricter. It passes only when SPF or DKIM passes for a domain aligned with the visible From address. A softfail isn't a pass, so DMARC falls back to DKIM. Microsoft's SPF documentation puts it plainly: DMARC treats -all and ~all as SPF failures. Our alignment guide covers what aligned means.

So the practical difference between ~all and -all shows up at a receiver without DMARC checking, which may refuse a hard fail outright and let a softfail through to the filter. Under DMARC, both endings leave an unlisted server to pass or fail on DKIM alone.

Forwarded mail produces softfails you didn't cause

When someone forwards your message, the forwarder's server delivers it. That server isn't in your record. If the forwarder kept your bounce address, the receiver checks your record, finds no match and reports softfail against your domain.

You'll see these in aggregate reports as small counts from IPs you don't recognise, often with a DKIM pass beside them. The DKIM pass is what keeps DMARC passing on those rows, as long as the forwarder didn't change the body. Don't add the forwarder to your record. It would authorise every message that server sends, for everyone who uses it.

Many forwarders rewrite the bounce address to their own domain instead. Then SPF passes for the forwarder's domain, doesn't align with yours, and the same forward shows up as an SPF pass with an alignment fail.

Adding a legitimate sender without breaking the record

Put the platform's include into your existing record. Never publish a second record, because two SPF records make both invalid. The include goes inside that one record, between v=spf1 and the ending.

Replace the placeholder with the include your platform documents. Then count the lookups. Every include, a, mx, ptr, exists and redirect term costs one, nested includes cost more, and the total may not pass 10. Past that the record returns permerror and receivers treat it as no SPF at all. Our lookup limit guide covers getting back under it.

Our SPF checker resolves each include and shows the count before you publish. Allow the old record's cache to expire before you retest, and send the test from the platform you just added rather than from your own mailbox.

Softfail on a server that should pass

If the platform is already in your record and still gets softfail, the record and the message disagree about the domain. Check smtp.mailfrom= in the header. Many platforms put their own domain in the bounce address, so the receiver checked their record, not yours. That passes for them and fails alignment for you. The fix is DKIM signing with your domain at that platform, or a custom bounce domain if the platform offers one.

If the domain is yours and the server is listed, check for a subdomain. SPF stops at the exact name in the bounce address. Mail from billing.example.com needs a record at billing.example.com, and never inherits the one at example.com.

If the record has a typo, a missing space or a stray character, the receiver reads something other than what you meant. Our syntax reference covers each term.

When to move from ~all to -all

Google's Workspace setup page publishes its example record ending in ~all, and that's the right starting point. A softfail stops receivers refusing mail from a sender you forgot while the reports show you who it is.

Move to -all once every platform that sends as your domain is in the record and each one signs with DKIM for your domain, so a forward still passes DMARC. Also wait until the list has stopped changing, so the next platform someone signs up to doesn't have its mail refused before you know it exists.

Once DMARC is enforcing, the ending matters less than it used to. Under p=reject, an unlisted server with no aligned DKIM is refused either way. Our p=reject guide covers the order to do it in.

Fixes to avoid

Don't switch to +all or ?all to make the softfail go away. With either ending you're telling receivers that anyone may send as you, and DMARC then depends on DKIM alone for every message.

Don't add a recipient's mail server or a forwarding service to your record because it appeared in a report. That row was a forward, and adding the server authorises a fleet you don't control.

Softfails also appear when the record changes without you knowing: a colleague adds a platform, or a platform changes its include. On a paid plan we email you the first time a source fails DMARC. The weekly digest shows the reported results by source and flags a change to your SPF record. Your first domain is free.

DomainCanary is a DMARC monitoring service that protects your domain from email spoofing without blocking your own mail.