SPF hard fail vs softfail

How the options were evaluated

The comparison uses the SPF result definitions in RFC 7208 first. It separates three questions that are often blended together: the domain's authorization statement, the result returned by SPF, and the receiver's final disposition. It also checks whether the option supports DMARC, which RFC 9989 defines independently through aligned SPF or DKIM pass results.

The practical criteria are simple: whether the sender inventory is complete, whether every legitimate route matches before all, whether the record stays within SPF processing limits, and whether the domain owner is prepared to describe every unmatched client as unauthorized. A receiver's spam, accept, or rejection decision is not a criterion because SPF leaves that decision to receiver policy.

Option 1: SPF hard fail with -all

Best fit: A domain with a tested, complete inventory of legitimate envelope-sender and HELO identities.

Relevant evidence: RFC 7208 defines - as the fail qualifier. A fail result is an explicit statement that the SMTP client is not authorized to use the evaluated identity.

Tradeoff: An omitted legitimate sender will also reach the final -all and return fail. That is a configuration gap to fix, not a reason to predict a single receiver outcome.

The all mechanism always matches. Mechanisms to its right are ignored, so an effective SPF policy puts all last. This illustrative record says an unmatched client is unauthorized:

v=spf1 include:_spf.example.net -all

This record is illustrative. Copy the mechanisms generated or documented for your own senders; do not publish the example values.

Option 2: SPF softfail with ~all

Best fit: A domain owner that intentionally wants to publish a weaker probable-non-authorization statement while it finishes evidence collection.

Relevant evidence: RFC 7208 defines ~ as softfail. It says receiving software should not reject a message based solely on a softfail result, while allowing closer scrutiny.

Tradeoff: Softfail does not authorize a missing sender, repair an invalid record, or guarantee delivery. It also does not turn an SPF result into a DMARC pass.

This illustrative record changes only the terminal qualifier:

v=spf1 include:_spf.example.net ~all

This record is illustrative. Copy the mechanisms generated or documented for your own senders; do not publish the example values.

An unmatched client reaches -all and returns fail in the first option. The same client reaches ~all and returns softfail in the second.

SPF does not prescribe one universal delivery action for fail. A receiver combines the result with local policy and other evidence. This is why -all does not guarantee rejection and ~all does not guarantee acceptance or spam placement.

Under RFC 9989, DMARC can use only an aligned SPF pass as its SPF authentication path. Neither fail nor softfail supplies that pass. DMARC's p policy is a separate control for the visible From domain.

How to choose

Choose -all when the evidence shows that every legitimate sending route matches before the terminal mechanism and the domain owner is prepared to state that all unmatched clients are unauthorized. Choose ~all only when the domain owner deliberately wants the weaker statement. Neither option is a deliverability shortcut.

There is no industry migration date from ~all to -all. The right trigger is operational evidence, not a calendar date. Use the same checklist for either policy and retain the previous record and TTL for rollback.

1. Inventory each SPF identity and sender

Build the inventory from delivered headers, SMTP logs, vendor documentation, and DMARC aggregate data. Record the envelope domain, sending IPs, service owner, and any HELO identity used for bounces or systems without a normal envelope sender.

2. Build one valid SPF policy

Publish one SPF record for the name being evaluated. Authorize each legitimate route with the provider-supported mechanism, remove abandoned services, and keep the complete evaluation within the RFC 7208 limit of 10 DNS-querying terms.

3. Test matched and unmatched clients

Send through every legitimate route and verify that it matches before all. In a controlled environment, evaluate an unauthorized client too, then confirm that it reaches the intended fail or softfail result.

4. Change the qualifier deliberately

Use -all when the domain owner is ready to state that every unmatched client is unauthorized. Use ~all only when the intended statement is probable non-authorization. Document the decision instead of treating either suffix as a deliverability shortcut.

5. Monitor after the DNS change

Review delivery logs, help-desk reports, delivered headers, and DMARC aggregate data through at least one normal sending cycle. Investigate an unexpected source before adding it to SPF because not every observed source is legitimate.

Check the public TXT answer with Palisade's SPF checker. Confirm there is one SPF record, the syntax is valid, all is last, and evaluation remains inside the 10-term DNS-query limit.

Read the delivered Authentication-Results and Received-SPF fields next. For each legitimate route, confirm the evaluated identity and sending IP match the intended mechanism. For an unmatched test, confirm the expected fail or softfail result without assuming a fixed delivery action.

Use DMARC aggregate data to find legitimate sources that lost an aligned pass. DMARC is the better view of visible-domain protection because it evaluates alignment and can also pass through DKIM.

Check the published SPF policy first

Run the domain through Palisade's SPF checker to inspect the published record before changing the qualifier. Compare its DNS result with the evaluated identity and connecting IP from a delivered message. The checker cannot reproduce a receiver's private disposition or prove that every legitimate sender is inventoried.

If repeated sender changes make the inventory difficult to maintain, Palisade's DMARC Agent remediation guide documents how report findings become source-specific SPF, DKIM, and alignment work. It does not choose the domain owner's authorization statement or guarantee receiver disposition. Get started when recurring report-based sender monitoring is the remaining need.