# SPF hard fail vs softfail > SPF hard fail uses -all and softfail uses ~all. Compare the authorization statements, receiver handling, and safe selection criteria. SPF hard fail and softfail differ in the statement a domain makes about an unmatched SMTP client. `-all` returns `fail` and says that client is not authorized. `~all` returns `softfail` and says it is probably not authorized. Neither result dictates a universal receiver action or replaces DMARC. Choose `-all` when every legitimate SPF identity and sending path is inventoried and tested. Use `~all` only when that weaker authorization statement is truly the policy you intend to publish. ## Quick takeaways - The `all` mechanism always matches, so it belongs at the end of an SPF policy. - `-all` produces `fail` for a client that did not match an earlier mechanism. - `~all` produces `softfail`, a weaker negative result for the same unmatched client. - A receiver decides how either result affects message disposition. - DMARC policy and alignment remain separate from the SPF qualifier. ## Who this comparison is for Every domain that publishes an SPF record has to decide what result an unmatched SMTP client receives. The risk comes from an incomplete sender inventory. A forgotten CRM, support platform, or device can reach the final mechanism even though the mail is legitimate. SPF evaluates an SMTP identity, not necessarily the address a person sees. The [SPF overview](/learning/what-is-spf) explains how the envelope sender is evaluated. The visible From domain is protected through the separate [DMARC](/learning/what-is-dmarc) alignment and policy layer, often with [DKIM](/learning/what-is-dkim) as another authentication path. An SPF hard fail means that the evaluated client reached a mechanism with the `-` qualifier, normally [the terminal `-all`](/learning/glossary/spf-all-qualifier). It does not prove that the visible From domain failed DMARC, and it does not identify why the client was unmatched. Preserve the evaluated identity, connecting IP, receiver result, and sending application before changing the record. ## How the options were evaluated The comparison uses the [SPF result definitions in RFC 7208](https://www.rfc-editor.org/info/rfc7208/) 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](https://www.rfc-editor.org/info/rfc9989/) 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](https://www.rfc-editor.org/info/rfc7208/) 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: ```text 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](https://www.rfc-editor.org/info/rfc7208/) 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: ```text 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. ![Decision flow for an SPF terminal qualifier, ending at the rule that a fail or softfail result still needs receiver evidence rather than a predicted delivery outcome.](/images/editorial/spf-hardfail-vs-softfail/spf-hardfail-vs-softfail-decision-flow.webp "1200x738") *Source: Result semantics follow [RFC 7208](https://www.rfc-editor.org/info/rfc7208/); final message disposition remains the receiver's local decision.* 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](https://www.rfc-editor.org/info/rfc9989/), 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](https://www.rfc-editor.org/info/rfc7208/). ### 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. ![Evidence checklist for choosing an SPF terminal qualifier without losing a legitimate sender.](/images/editorial/spf-hardfail-vs-softfail/spf-hardfail-vs-softfail-qualifier-checklist.webp "1200x582") *Source: The checklist applies the authorization, processing-limit, and receiver-evidence rules in [RFC 7208](https://www.rfc-editor.org/info/rfc7208/).* Check the public TXT answer with Palisade's [SPF checker](/tools/spf). 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](/tools/spf) 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](https://docs.palisade.email/guides/fixing-authentication-issues/) 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](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=spf_policy&utm_content=spf-hardfail-vs-softfail) when recurring report-based sender monitoring is the remaining need. ## Sources and further reading - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/info/rfc7208/) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/info/rfc9989/) - [Palisade guide to fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Does `-all` force receivers to reject mail? No. It returns SPF `fail`. The receiver chooses the final disposition using local policy and other evidence. ### Is `~all` safer during setup? Not automatically. It is a weaker authorization statement, but it does not repair a missing sender or invalid SPF record. Monitor and fix legitimate routes before relying on either result. ### Does `-all` mean DMARC `p=reject`? No. The SPF qualifier describes authorization for an SPF identity. DMARC policy and alignment govern the visible From domain. ### Can forwarding cause SPF `fail`? Yes. Traditional forwarding changes the SMTP client seen by the final receiver, so the forwarder's IP may not be authorized by the original envelope domain. A surviving aligned DKIM signature can provide the other DMARC pass path. ### Can a non-sending domain publish `v=spf1 -all`? Yes. That record states that no SMTP client is authorized for the evaluated SPF identity. Publish and validate a separate DMARC policy when the goal also includes protection of the visible From domain.