The all mechanism always matches. Its qualifier therefore determines what SPF says about a connecting address that reaches it. The familiar endings -all, ~all, ?all and +all are four different authentication statements, not four guaranteed delivery actions.
An earlier mechanism may already have returned a result. Read the whole evaluation path before interpreting the last word of the record. RFC 7208 §2.6 and RFC 7208 §5.1 define these semantics.
Compare the four endings
With -all, a sender that reaches all receives fail. The policy says that address is not authorised for the evaluated identity. With ~all, it receives softfail, a weaker negative statement rather than a pass. With ?all, it receives neutral, meaning the policy is not making an authorisation assertion for that address. With +all, it receives pass.
Under RFC 7208 §4.6.2, an unqualified all has the default + qualifier and therefore also passes. That makes a bare all a consequential permission choice, not a harmless terminator. Once all matches, later mechanisms cannot contribute additional permissions.
Worked example: keep the authorised sender constant
Use the synthetic policy v=spf1 ip4:192.0.2.90 QUALIFIERall. For a connection from 192.0.2.90, ip4 matches first and returns pass under every ending. For 192.0.2.91, the first mechanism does not match. The chosen ending then returns fail, softfail, neutral or pass respectively.
Changing ~all to -all does not change the result for the first address in this fixture. It changes the treatment of addresses that were not already matched. That is why the right readiness question is whether all legitimate sending paths have been identified, not whether a common sender passed one test.
A policy consisting of v=spf1 -all authorises no addresses through SPF. It can express a non-sending identity, but it is not a universal instruction that every receiver must discard every message displaying that domain in From.
Keep result and handling separate
SPF returns an authentication result. The receiver decides what to do with the message using local policy and other evidence under RFC 7208 §8.4 and RFC 7208 §8.5. A fail is not proof that every receiver rejected the message, and softfail is not a promise that it will be delivered with a warning.
SPF softfail and neutral do not become passing SPF paths for DMARC. Under RFC 9989 §4.4.2, DMARC requires a pass with alignment for its SPF path, or a separate passing aligned DKIM path. A message can therefore pass DMARC through DKIM despite SPF fail. Conversely, +all can produce SPF pass for an address without making its content trustworthy.
Do not use +all to silence an error dashboard. It authorises every address that reaches it for that identity and defeats the intended restriction. Repair missing senders, incorrect identities or broken dependencies instead.
Distinguish policy endings from evaluation errors
Permerror and temperror are not other spellings of fail. Multiple SPF records, invalid syntax or exceeded processing limits can prevent normal evaluation. Temporary DNS problems can produce temperror. Replacing -all with ~all does not repair an error that occurs before the ending is reached.
Collect the actual result and trace before choosing a change. For a DNS outage, investigate the dependency and resolver path. For an unrecognised legitimate sender, establish its owner and expected envelope identity before granting it permission.
Roll out a stricter statement with evidence
Inventory regular, failover, IPv6 and infrequent sending routes. Test the proposed policy against those addresses and an unauthorised control. Keep the previous record, define service-based rollback conditions and verify received mail after publication.
Where forwarding is part of legitimate delivery, review the wider authentication design, including aligned DKIM and receiver behaviour. Do not broadly authorise unknown forwarders to make every indirect SPF path pass.
The practical takeaway
Choose the qualifier for the statement you intend to make about otherwise unmatched senders. Verify the inventory and error paths first, then measure authentication and delivery as separate outcomes.
Record the next decision
For 192.0.2.91 in the synthetic fixture, the four endings yield fail/softfail/neutral/pass respectively; 192.0.2.90 remains pass through the earlier ip4 match. If a syntax or dependency error occurs before a normal result, changing the final qualifier is not a repair. These are analytical control-flow outcomes, not delivery tests.