SPF Softfail vs SPF Hardfail: Key Differences Explained

The final mechanism in an SPF record often determines what should happen when the sender does not match any authorised source. Two of the most common options are SPF softfail, represented by ~all, and SPF hardfail, represented by -all.

Although they differ by only one character, they communicate different levels of confidence about unauthorised senders. A softfail suggests that the sender is probably not authorised, while a hardfail explicitly states that the sender is not authorised.

Key Takeaways

• SPF softfail uses ~all and indicates that an unlisted sender is probably unauthorised.
• SPF hardfail uses -all and explicitly states that an unlisted sender is unauthorised.
• Softfail messages are usually accepted but may receive additional scrutiny or be placed in spam.
• Hardfail creates a stronger negative signal, but receivers are not universally required to reject the message.
• Softfail is often used while identifying and validating legitimate sending services.
• Hardfail should generally be considered only after all authorised senders have been documented.
• SPF alone does not protect the visible From address and should be combined with DKIM and DMARC.

What Is SPF?

 
SPF is an email authentication protocol that allows a domain owner to publish a list of authorised email-sending systems in the Domain Name System, or DNS.

When a mail server receives a message, it checks the SPF policy associated with the relevant SMTP identity, usually the domain in the envelope-from or Return-Path address. SPF does not directly authenticate the visible From address that recipients see in their email client. DMARC is needed to connect SPF or DKIM authentication with that visible domain.

What Is SPF Softfail?

 
An SPF softfail occurs when a sending server does not match an authorised source and the SPF record uses the ~all mechanism.

Example:

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

In this record, the specified IP address and the sources authorised by _spf.example.net are permitted to send email. Any other sending source produces an SPF softfail result.

What happens after an SPF softfail?

 
A receiving server will normally avoid rejecting a message solely because of a softfail. However, it may:

• Accept the message normally
• Place the message in the spam folder
• Add the result to its spam-scoring system
• Examine the message more closely
• Check DKIM, DMARC, sender reputation and content signals
• Add an authentication warning or header

The precise outcome depends on the recipient’s filtering rules. A softfail does not guarantee inbox delivery, nor does it guarantee that the message will be accepted.

When is SPF softfail useful?

 
Softfail is commonly used when:

• SPF is being implemented for the first time
• The organisation is still discovering its sending services
• Multiple third-party platforms send email for the domain
• The infrastructure changes frequently
• Legitimate forwarded messages are a concern
• The administrator wants to monitor failures before applying stricter rules

For example, a business may send messages through Google Workspace, a CRM platform, a support system and an email marketing provider. If one service is accidentally omitted from the SPF record, ~all reduces the chance that its legitimate messages will be immediately rejected based on SPF alone.

Softfail can therefore provide a useful transition period. It should not, however, become a substitute for properly identifying and managing authorised senders.

What Is SPF Hardfail?

 
SPF hardfail, formally called an SPF fail result, occurs when a sender does not match an authorised mechanism and the SPF record ends with -all.

Example:

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

In this case, the domain owner explicitly states that any server not covered by the preceding mechanisms is not authorised to use the domain for the evaluated SPF identity.

SPF fail result is an explicit statement that the client is not authorised to use the domain in the relevant identity.

What happens after an SPF hardfail?

 
An SPF hardfail creates a stronger negative authentication signal than softfail. Depending on the receiving system’s policy, the message may be:

• Rejected during the SMTP transaction
• Accepted and sent to spam
• Evaluated using additional authentication signals
• Quarantined for further analysis
• Blocked when combined with poor reputation or other suspicious indicators

It is common to describe -all as instructing receivers to reject unauthorised messages. However, SPF does not force every receiver to apply the same action. Final message handling remains the responsibility of the receiving mail system.

When is SPF hardfail appropriate?

 
Hardfail may be appropriate when:

• Every legitimate sending source is known
• The organisation has a stable email infrastructure
• Third-party sending services are carefully documented
• SPF changes are tested before deployment
• The domain has active DMARC reporting
• Administrators can quickly identify and fix authentication problems
• The risk of domain abuse outweighs the risk of false-positive rejection

Publishing -all without a complete sender inventory can disrupt password resets, invoices, support notifications, marketing campaigns and other legitimate messages.

Does SPF Hardfail Automatically Reject Email?

 
Not necessarily.

The term “hardfail” is widely used to describe the SPF fail result associated with -all. It communicates a definitive policy, but the recipient retains control over delivery.

Some mail systems may reject the message immediately. Others may consider additional factors, including:

• DKIM authentication
• DMARC alignment and policy
• Sending IP reputation
• Domain reputation
• Previous recipient engagement
• Message content
• Spam complaints
• Allow lists
• Forwarding behaviour

Consequently, -all should not be treated as a universal guarantee that every unauthorised message will be rejected.

Softfail vs Hardfail Under DMARC

 
DMARC evaluates whether SPF or DKIM passes and aligns with the domain visible in the From header.

For SPF to contribute to a DMARC pass:

1. SPF must return a pass result.
2. The SPF-authenticated domain must align with the visible From domain.

Neither an SPF softfail nor an SPF hardfail counts as an SPF pass for DMARC. However, a message can still pass DMARC through aligned DKIM even when SPF fails.

This is one reason you should avoid treating SPF as a complete anti-spoofing solution. SPF authenticates a particular SMTP identity, while DMARC connects authentication with the domain users actually see.

A platform such as DMARKOFF can help domain owners review DMARC data and identify which services are passing or failing authentication before stricter policies are introduced.
 
Start 14-day Free Trial
 

Best Practices for Managing SPF

 

1. Identify every legitimate sender.

 
Create an inventory covering all systems that send mail using your domains, including:

• Employee mailboxes
• Marketing automation tools
• Customer support platforms
• Transactional email providers
• Billing and payment systems
• Recruitment platforms
• Survey tools
• Website contact forms
• Security alert systems

2. Publish only one SPF record.

 
A domain should not have multiple SPF records beginning with v=spf1. Multiple records can produce an SPF permanent error.

Combine authorised sources into a single valid record instead.

3. Configure DKIM.

 
DKIM provides an additional authentication path and is generally more resilient to basic forwarding. Important email streams should use valid DKIM signatures aligned with the visible From domain whenever possible.

4. Implement DMARC reporting.

 
DMARC aggregate reports reveal how receivers evaluate mail claiming to come from your domains. They can expose unknown services, alignment problems, unauthorised sending and configuration errors.

Tools like DMARKOFF can be used to monitor this reporting data and help distinguish legitimate email sources from suspicious or misconfigured traffic.
 
Secure Your Brand
 

5. Test before tightening the policy

 
Before changing ~all to -all, verify that:

• Every authorised provider is covered.
• Transactional messages pass authentication.
• Marketing campaigns pass authentication.
• DKIM is working as a backup authentication method.
• SPF does not exceed the lookup limit.
• DMARC reports do not show unexplained legitimate failures.
   

6. Review SPF after infrastructure changes.

 
SPF is not a one-time configuration. Review the record whenever your organisation changes email providers, introduces new SaaS platforms or retires old systems.

Conclusion

 
SPF softfail uses ~all and indicates that an unlisted sender is probably not authorised. It is commonly used during implementation, testing and sender discovery because receiving systems are generally discouraged from rejecting a message solely because of this result.

SPF hardfail uses -all and explicitly states that an unlisted sender is not authorised. It creates a stronger authentication signal, but the receiving provider still controls the final delivery decision.

Softfail can reduce disruption while an organisation maps its email environment. Hardfail can provide a clearer policy once all sending services are known and tested. In either case, SPF should be supported by DKIM, DMARC reporting, alignment monitoring and regular record maintenance.