Threat analysts and researchers sharing practical guidance on phishing response, digital risk monitoring, and incident workflows.
SPF softfail is one of the most misread signals in email authentication. Many tools flag it as a problem. It is not always one.
Understanding what softfail actually does — and when it is appropriate — is important before changing anything in your DNS.
An SPF record ends with a catch-all mechanism that tells receiving mail servers what to do when an email arrives from a sender not listed in the record. There are four options:
| Qualifier | Mechanism | Meaning |
|---|---|---|
+ | +all | Pass — accept all senders (insecure, rarely used) |
~ | ~all | Softfail — accept but flag as suspicious |
- | -all | Fail — reject senders not in the record |
? | ?all | Neutral — make no assertion |
When your SPF record ends with ~all, any email from a server not listed in the record is delivered but marked as a softfail. Receiving mail servers may use this flag to adjust spam scoring, but they are not required to reject the message.
Softfail was designed as a transition mechanism, not a permanent weakness.
When an organisation first publishes an SPF record, they often do not have a complete picture of every system that sends email on their behalf — third-party marketing platforms, ticketing systems, CRM tools, automated notifications, and so on.
Setting ~all during this discovery period allows legitimate mail to keep flowing while the organisation identifies all sending sources. It prevents broken delivery caused by an incomplete record.
Softfail makes sense in several situations:
p=none or p=quarantine, the practical difference between softfail and hardfail is small; changing SPF before DMARC enforcement is ready adds risk without benefitSoftfail becomes a concern when it is permanent rather than transitional.
If your DMARC policy is p=reject and you want strong enforcement against spoofing, your SPF record should ideally end with -all to make the rejection signal unambiguous. Some receiving mail servers also have configurations that treat a DMARC pass differently depending on whether the underlying SPF result was a fail or a softfail.
The other scenario where softfail causes issues is when it is used with no DMARC record at all. Without DMARC, the softfail signal from SPF is advisory only — receiving servers vary widely in how much weight they give it.
Rather than treating softfail as something to fix immediately, treat it as a signal to investigate:
p=reject, review whether all your legitimate senders are listed in SPF and whether changing to -all would affect deliveryrua) to identify all systems sending as your domain before tightening SPF~all to -all only once you are confident your SPF record is complete and your DMARC policy is enforcedRushing from softfail to hardfail without a complete picture of your sending environment is one of the most common causes of broken email delivery.
Softfail (~all) | Hardfail (-all) | |
|---|---|---|
| Non-listed senders | Delivered, may be flagged | Rejected |
| Risk of broken delivery | Low | Higher if record is incomplete |
| Appropriate when | Auditing senders, DMARC not yet enforced | Record is complete, DMARC at p=reject |
| Protection against spoofing | Partial — relies on recipient handling | Stronger — instructs rejection |
Softfail is not a misconfiguration. It is a deliberate posture that is correct in many environments. What matters is whether it is intentional, whether it is paired with a DMARC record, and whether there is a plan to move to stricter enforcement once the sending environment is understood.
If you are unsure whether your current SPF and DMARC configuration is appropriate for your risk level, JSsec can review it.