Deliverability · Practical guide

SPF softfail vs hardfail: choose the final disposition deliberately

Understand what ~all and -all express, then base a policy change on a complete legitimate-sender inventory.

Reviewed · Examples are illustrative

Who this helps: Operators diagnosing authentication, receiving-policy and delivery failures.

Define the decision

Changing the final qualifier is not a repair for missing authorization. If a legitimate sender fails because it is absent from the record, identify that path first. Receiver handling also includes policies beyond SPF.

Work through the procedure

  1. Collect failures by envelope domain and sending service.
  2. Separate known legitimate senders from unknown sources.
  3. Repair missing legitimate authorization and retest each stream.
  4. Have the domain owner choose the final policy after reviewing the remaining failures.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Known invoice sender fails SPF
Current ending: ~all
Proposed shortcut: change to -all
Better decision: fix invoice authorization, then assess the final disposition with the owner

Read the result

Softfail signals weaker disapproval than fail. Neither setting should be interpreted as a universal delivery outcome, and a passing unrelated SPF identity still may not satisfy DMARC alignment.

Check before moving on

  1. Retain a sample from each legitimate service.
  2. Check the full receiver response rather than attributing every rejection to the qualifier.

Limits and next action

Do not promise that changing ~all to -all improves inbox placement. The operational goal is an accurate policy, with monitoring and rollback for affected legitimate mail.

Source: RFC 7208: SPF result meanings

Source references

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.

Related guides

Explore the Zintara workflow