All Collections
Learn about SPF
SPF Hard fail vs SPF Soft fail
SPF Hard fail vs SPF Soft fail

A hardfail indicates that an email isn't authorized and should be rejected, whereas a softfail suggests an email should be diverted to spam.

Ivan Kovachev avatar
Written by Ivan Kovachev
Updated over a week ago

What is SPF, or Sender Policy Framework?

SPF (Sender Policy Framework) is a DNS-based record that verifies the MAIL

FROM or HELO/EHLO identities during email transmission. It serves as a powerful tool against sender address forgery. When an email is sent from a domain the receiving server will check the SPF records to see if the email has been sent from an authorized IP address. These IP addresses are specified in a TXT record that is published in the domain owner’s DNS. This list is known as the SPF record.

Here is an example of an SPF record published on domain X, authorizing Microsoft 365 to send emails on its behalf:

v=spf1 include.spf.protection.outlook.com ~all

What is an SPF failure?

An SPF failure occurs when the sender's IP address is not found in the SPF record published. Failures significantly affect the deliverability of your email as they result in the email being sent to spam or discarded altogether. This can be catastrophic for businesses that rely on email to reach customers.

There are two types of SPF failures - SPF softfail and SPF hardfail. A hardfail indicates that an email is definitely not authorized, whereas a softfail means that an email has probably not been authorized. For the email recipient, it determines the treatment of the email; a hardfail tells the recipient to reject the email, whereas a softfail suggests it should be diverted to spam.

We will use two examples to demonstrate the visual difference between both.

SPF hardfail example

v=spf1 ip4:192.168.0.1 -all

In the above example the minus symbol (in front of “all” at the end of the record) means that any senders not listed in this SPF record should be treated as a "hardfail", ie. they are unauthorized, and emails from them should be discarded. In this case, only the IP address 192.168.0.1 is authorized to send emails and nothing else.

SPF softfail example

v=spf1 include:spf.protection.outlook.com ~all

In the above example the tilde symbol (in front of “all” at the end of the record) means that any senders not listed in this SPF record should be treated as a "softfail", ie. mail can be allowed through but should be tagged as spam or suspicious. In this case, the include:spf.protection.outook.com mechanism authorizes Microsoft 365 to send emails. Any emails originating from different servers should be marked as spam by the receivers. 

Why SPF isn't enough and you still need DMARC

Irrespective of which failure mode you specify in your SPF record, receiving servers are unlikely to honour your requested policy. This is because SPF is limited in that:

  1. It does not require alignment between the domain in the FROM field and the Return-Path address it checks. They don't have to match from an SPF perspective.

  2. SPF does not provide reporting functionality, meaning the receiver does not send back reports to the sender containing the results of email authentication.

  3. SPF does not survive auto-forwarding and indirect mail-flows, which can lead to authentication issues.

Due to these limitations, DMARC (Domain-based Message Authentication, Reporting, and Conformance) was introduced as an additional email authentication standard. DMARC addresses the shortcomings of SPF and provides the following enhancements:

  1. DMARC focuses on the visible "From" header, which is seen by end-users.

  2. DMARC requires alignment between the domain used by SPF and the visible "From" address in the email.

  3. DMARC ignores the nuances of soft fail and hard fail in SPF configuration, treating them as SPF failures.

  4. DMARC provides reporting functionality, allowing email authentication results to be sent back to the owner of the "From" domain. This helps identify domain misuse and troubleshoot any misconfigurations with legitimate email senders.

  5. DMARC includes a policy that instructs receivers on how to handle emails that fail authentication, and receivers enforce this policy. In contrast, SPF alone does not have enforcement mechanisms.

DMARC has gained widespread adoption as an authentication requirement as it overcomes the shortcomings of SPF (and DKIM), blocks exact email impersonation, and improves email deliverability.

Interesting in checking your SPF configuration?

Our free tool, called Investigate, checks your email configuration, including your SPF, DKIM, and DMARC records, to ensure that you're authenticating your emails correctly. Simply follow the link below, send an email to the address from the sending service you wish to check, and get your results in seconds!

Did this answer your question?