SPF Hardfail vs Softfail: When to Use -all or ~all

One SPF character can break real mail

The last tag in an SPF record often looks tiny: ~all or -all. That choice tells receivers how strongly your domain disowns mail from IPs you did not list.

SPF checks whether the connecting mail server is allowed to send for the envelope sender domain, also called the MAIL FROM or return-path domain. SPF can also check the HELO name in some cases. It does not directly check the visible From address that a person sees in their inbox.

The all mechanism is the catch-all at the end of the record. SPF is read left to right. When a mechanism matches, evaluation stops and returns that result. Earlier mechanisms might be ip4, ip6, a, mx, include, or exists.

~all is SPF softfail. It means the sender is probably not allowed, but the domain owner is not asking receivers to treat that result as final. Many receivers accept the message and use softfail as one spam signal.

-all is SPF hardfail. It means the sender is explicitly not allowed. Receivers can reject the message, put it in spam, or combine the result with DMARC, reputation, and local policy. RFC 7208 defines the SPF result. It does not force Gmail, Outlook, or any other receiver to take one exact action.

The practical rule is simple: use ~all while you are still finding legitimate senders. Use -all after your SPF record is complete, DKIM is signing real mail, and DMARC reports show your mail is passing alignment.

What ~all and -all mean

SPF qualifiers are short, but they carry the policy for every sender that reaches them.

• +all means pass. Do not use it on a real sending domain because it allows every IP address.
• -all means fail, often called hardfail. Use it when all legitimate senders are listed and tested.
• ~all means softfail. Use it during rollout, migrations, and audits.
• ?all means neutral. It makes no clear claim and rarely helps.

A record such as v=spf1 include:_spf.google.com include:sendgrid.net -all says Google and SendGrid may send for that SPF domain, and everyone else should fail SPF. If you leave off all, SPF has an implicit neutral result at the end, but an explicit ending is easier to read and debug.

Do not treat -all as an inbox switch. It can reduce spoofing from unauthorized IPs, but mailbox providers still look at domain reputation, IP reputation, complaints, blocklists, content, forwarding behavior, unsubscribe handling, and authentication results. Passing SPF never guarantees inbox placement.

Choose by audit risk, not by ego

Hardfail is right only when your sender map is right.

Use ~all if you recently changed email tools, added a CRM, send through a support desk, use several SaaS senders, or have not reviewed DMARC aggregate reports yet. Softfail gives you time to find missing systems before they lose mail.

Use -all when your sending list is stable. That means your main mailbox provider, transactional mail service, marketing platform, support desk, billing system, and product systems are covered. Remove old vendors once they stop sending.

SPF alone is not enough for modern deliverability. A good setup has SPF for the return-path domain, DKIM signatures using provider selectors, and DMARC on the visible From domain. DMARC passes when SPF or DKIM passes and aligns with the From domain. If your provider uses a different return-path domain, SPF may pass but fail DMARC alignment unless that domain aligns. DKIM is often the steadier DMARC path because forwarding can break SPF while DKIM can survive if the signed content is not changed.

If you are unsure, keep ~all, publish DMARC at p=none with a rua reporting address, study the reports, then move DMARC toward quarantine or reject after real senders pass. Use the source rules when checking details: RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, plus the Google and Microsoft sender guidelines.

Check these before switching to -all

Most SPF failures are inventory mistakes. Tighten the policy after the basics are clean.

• Publish only one SPF TXT record that starts with v=spf1 for each SPF domain. Multiple SPF records can cause SPF permerror.
• Stay under SPF's 10 DNS lookup limit. RFC 7208 counts include, a, mx, ptr, exists, and redirect. ip4, ip6, and all do not count.
• Check that each third-party sender uses the return-path or include value they document. Guessing here creates silent gaps.
• Turn on DKIM for every provider that supports it. The selector in the DKIM-Signature header points receivers to the public key in DNS.
• Publish DMARC with reports first. Raise policy only after reports show legitimate mail passing SPF or DKIM alignment.
• Check MX records, forward and reverse DNS for dedicated sending hosts, and major blocklists if delivery drops.

Google says all senders to Gmail need SPF or DKIM, and bulk senders need SPF, DKIM, and DMARC. Microsoft says high-volume Outlook.com senders need SPF, DKIM, and DMARC, with authentication aligned to the visible From domain. These rules are a floor. They do not replace consent, clean lists, low complaint rates, sane volume, or useful mail.

If you want a fast outside check, run the free InboxRadar scorecard at the domain checker. It can spot drift in SPF, DKIM, DMARC, MX, and blocklist signals before a small DNS change turns into a delivery problem.