SPF ~all vs -all: What Is the Difference?
~all requests an SPF softfail for unmatched senders, while -all requests fail; neither qualifier is universally right without knowing every legitimate sender.
How it works
The all mechanism is usually last in an SPF record and applies when earlier mechanisms do not match. A bare mechanism means +, while - requests fail, ~ requests softfail, and ? is neutral.
The qualifier applies to the mechanism that follows it. In v=spf1 include:_spf.example.com ~all, sources authorized by the include can pass, while every unmatched source produces softfail. Replacing the final token with -all asks for fail instead. It does not authorize another provider, repair a missing include, or change the envelope domain a service uses.
Softfail is often useful during a measured migration because it records that an unmatched sender is unexpected without assuming that every receiver will reject it. That is not a reason to leave a policy unreviewed forever. It gives an owner time to discover a forgotten SaaS sender, a help-desk system, or a relay before an enforcement change affects legitimate mail.
Hardfail is a good fit only after the sender inventory is accurate. List each legitimate service, use its documented SPF mechanism, and remove old providers deliberately. If an employee forwards mail through another server, the forwarding path can produce an SPF failure even when the originating domain is configured correctly. That is a mail-flow issue, not evidence that every forwarded message is forged.
DMARC changes the decision context. A message that passes SPF for bounce.vendor.example can still fail DMARC for visible From: example.com when those domains are not aligned. Changing ~all to -all does not create alignment or configure DKIM. Review actual authentication results and the visible From relationship before treating a stricter final qualifier as a complete solution.
Use the checker to read the published policy and identify its direct mechanisms, then confirm changes with the providers that send mail. It does not simulate a message, recursively evaluate every include, or decide how a recipient will treat softfail or fail. The safest progression is evidence first, then a policy that accurately represents the systems you control.
Softfail and hardfail in practice
A record ending ~all says the sender was not authorized but leaves receivers discretion about treatment. A record ending -all makes a firmer failure request. Receivers still combine SPF with local policy, reputation, and DMARC, so neither line alone guarantees an inbox result.
For example, v=spf1 include:_spf.mail.example ~all can be a monitoring-stage policy while a sender inventory is incomplete. The equivalent -all can be appropriate after legitimate systems have been confirmed. +all matches every sender and is usually unsafe; ?all expresses neutral handling.
Choose based on readiness
Changing immediately to -all can disrupt real mail from an overlooked billing system, help desk, or marketing provider. SPF also has forwarding limitations: a forwarder may relay mail from an IP not authorized by the original envelope domain. Investigate the envelope sender and source path before editing a policy.
Use a staged approach: identify all senders, publish the provider-approved mechanisms, review direct DNS lookup-causing terms, and monitor DMARC alignment. DMARC evaluates alignment with visible From, so an SPF pass for an unrelated envelope domain may still not satisfy DMARC.
Practical guidance
- Inventory every legitimate sender before tightening policy.
- Do not merge multiple v=spf1 records.
- Use DMARC monitoring to review alignment before enforcement.
Common question
Is -all always better? No. It is only appropriate when the published policy accurately covers legitimate sending paths.