What Does SPF Softfail ~all Mean?

SPF softfail means your domain is warning, not blocking

In an SPF record, ~all is the softfail ending. It means every sender not already allowed by the record is probably not authorized, but the domain is not asking receivers to reject that message based on SPF alone.

Example: v=spf1 include:_spf.google.com include:sendgrid.net ~all says Google and SendGrid may send for the domain. If another server sends with that domain in the envelope sender, SPF returns softfail. The receiver can use that result as a negative signal, add it to spam filtering, or combine it with DKIM, DMARC, reputation, content, user feedback, and local policy.

Softfail is not the same as pass. It is also not a guaranteed spam folder verdict. Gmail, Outlook, and other mailbox providers make delivery decisions from many signals. But a softfail from a real message source means your SPF record is missing a sender, the service is using the wrong envelope domain, or the message is being forwarded in a way that broke SPF.

~all vs -all vs ?all

The symbol before all tells receivers what result to return when none of the earlier SPF mechanisms match.

• ~all: softfail. Use this while you are still finding every legitimate sender or when forwarding makes hard SPF failure risky.
• -all: fail. Use this only when you are confident every sending source is listed and DKIM plus DMARC are working.
• ?all: neutral. This says you are not making a useful claim for unmatched senders.
• +all: pass for everyone. Do not use it. It authorizes the internet to send as your domain.

A good SPF record usually starts with v=spf1, lists your real sending systems with include:, ip4:, or ip6:, then ends with ~all or -all. Publish only one SPF TXT record for a domain. Multiple SPF records can cause a permanent error, which is worse than a clean softfail.

Why softfail can still hurt deliverability

SPF is only one part of authentication, but a softfail tells filters that the sending server was not on your authorized list.

For normal business mail, that often happens after a new tool starts sending email before DNS is updated. For marketing or transactional mail, it can happen when the provider asks you to add an SPF include and it never made it into DNS. For forwarded mail, SPF can fail because the forwarding server is now the connecting IP, even though the original sender was legitimate.

DMARC is what turns SPF and DKIM into a domain-level policy. DMARC passes when SPF or DKIM passes and aligns with the visible From domain. A domain can start with p=none to collect reports, then move to p=quarantine or p=reject after the legitimate streams are passing. Add rua=mailto:... so aggregate reports show which systems are passing or failing authentication and alignment.

DKIM matters because it survives many forwarding paths better than SPF. Your email provider signs mail with a selector, such as google._domainkey or a provider-specific selector, and receivers verify the signature with the public key in DNS. If DKIM passes and aligns, DMARC can still pass even when SPF breaks during forwarding.

How to fix a softfail result

Do not switch from ~all to -all until the legitimate sender is passing. First identify why the message missed your SPF allow list.

• Check the live SPF TXT record at the exact sending domain. SPF follows the envelope sender or HELO domain, not always the visible From address.
• Make sure there is one SPF record only. Merge duplicate records into one line that starts with v=spf1.
• Add every real sender your domain uses, including Google Workspace, Microsoft 365, your CRM, help desk, invoicing tool, and email service provider.
• Stay under the SPF 10 DNS-lookup limit. The lookup count applies to mechanisms and modifiers such as include, a, mx, ptr, exists, and redirect. Plain ip4, ip6, and all entries do not add DNS lookups.
• Turn on DKIM signing for every sender that supports it. Publish the selector record exactly as the provider gives it.
• Publish DMARC at _dmarc.yourdomain. Start with p=none and reporting, then tighten after the reports show clean alignment.
• Confirm MX records if the domain receives mail. MX does not authorize outbound senders, but broken receiving DNS can still damage trust and operations.
• Check major blocklists if authentication is correct but Gmail or Outlook still sends mail to spam. Blocklists are not the first fix, but they are worth ruling out after SPF, DKIM, and DMARC pass.

You can run a free InboxRadar domain scorecard to see your SPF, DKIM, DMARC, MX, and drift risks in one place. For more background, see the other InboxRadar email deliverability guides.

What the official specs and providers say

The short version is stable: SPF authorizes sending hosts, DKIM signs messages, and DMARC checks alignment against the From domain.

RFC 7208 defines SPF, including softfail handling and the 10-lookup processing limit. RFC 6376 defines DKIM signatures and selectors. RFC 7489 defines DMARC policies, alignment, and aggregate reporting. Google sender guidelines say senders should authenticate mail and that DMARC passes when SPF or DKIM authenticates with the same domain used in the From header. Microsoft's published Outlook high-volume sender guidance also treats SPF, DKIM, and DMARC as core sender authentication requirements.

That means ~all is not a magic deliverability fix. It is a cautious SPF policy. The best setup is a correct SPF record, DKIM signing for each sender, DMARC reporting and enforcement, clean MX records, and a sender reputation that stays off blocklists.