SPF Softfail Vs Hardfail: What’s the Difference?
by
Reading Time: 5 min
SPF or Sender Policy Framework is an email authentication Protocol that helps verify the legitimacy of sending sources. Used in combination with DMARC, SPF can help prevent email-borne cyber attacks like phishing and direct-domain spoofing.
Through minor tweaks to the SPF record syntax, emails failing SPF can be handled in two completely different ways! SPF can be configured to either trigger a Hardfail error or a Softfail error when sender authentication fails. In this blog, we are going to discuss the differences between SPF hardfail and softfail, the syntax to configure both, and their use cases. So let’s dive right in!
How Do SPF Records Work?
To implement SPF for your emails, you need to create and publish an SPF record on your domain’s DNS. A typical example of an SPF record is as follows:
v=spf1 include:_spf.google.com ~all
In this SPF record, you are authorizing all emails originating from IP addresses listed in Google’s SPF record. The failure mechanism is defined at the very end of the record (~all), ie. Softfail.
Hence, an SPF record defines the protocol version used, the sending sources you’re authorizing, and the failure mechanism. When you publish this record on your DNS, you ensure that only authorized senders are allowed to send emails on your domain’s behalf. If an unauthorized source tries to impersonate you, SPF fails with the type of failure mechanism defined in your record.
Difference between SPF Hardfail and Softfail
The table provided below explains the basic difference between SPF hardfail and softfail.
| SPF Syntax | Type of Fail | Status | Corresponding action taken by the recipient |
|---|---|---|---|
| v=spf1 include:domain1.com -all | Hardfail | Sender unauthorized | Email may be rejected |
| v=spf1 include:domain1.com ~all | Softfail | Sender may be unauthorized | Email is delivered but marked as suspicious or potentially fraudulent |
SPF Hardfail Vs Softfail : As Defined in RFC
According to RFC 7208:
- A “Fail” result for SPF directly indicates that the sender of the email is not authorized by the sending domain. “Fail” is synonymous with the Hardfail result (-all) which is clearly indicative of unauthorized domain usage.
- However, a much more relaxed approach is configuring SPF Softfail, which indicates a “probable” indication of unauthorized domain usage.
Recipient Failure Handling for Hardfail Vs Softfail
In section 8.4, RFC defines the following result handling scenarios for SPF hardfail vs for SPF softfail results:
1. SPF Hardfail / Fail
For the “Fail” or hardfail result, your recipient server may choose to reject the email that is unauthorized. If it’s an SMTP transaction, a 550 5.7.1 error code should be returned with an appropriate error description.
IF the recipient server does not reject the email during the SMTP transaction then, RFC recommends receivers to record the SPF results in the Received-SPF or Authentication-Results header.
2. SPF Softfail
As a more flexible policy, Softfail indicates that the administrative management domain does suspect the email to be unauthorized, however it doesn’t wish to outright reject it. In this case, the message is delivered, but with a warning for further review.
SPF Softfail Vs Hardfail: What Do We Recommend?
In the case of SMTP email relaying, you may consider SPF softfail as a safer bet against hardfail. Let’s find out how:
SMTP email relaying is the automatic transfer of messages from one server to another delivery. This means that the email is handed over to a server whose IP address is not listed within your domain’s SPF record. This makes it an unauthorized sender for your email, although, in practicality, it is legitimate.
Do you have any control over this activity? The answer is no as the email is relayed automatically on your recipient’s side. Under these circumstances, SPF will fail for the relayed emails.
Here’s where having an SPF hardfail policy may land you in trouble! As we already know, the hardfail mechanisms may lead to the rejection of failed messages. Hence, these relayed emails may fail to get delivered if your domain is configured with a hardfail policy.
The worst part? The action taken by the SPF failure handling policy will override DMARC and DKIM authentication results. Essentially, even if DKIM and subsequently DMARC passes – the email may still fail to get delivered.
As specified under RFC 7489 Section-10.1 if SPF checks are performed before DMARC operations, the presence of a “-” prefix on a sender’s SPF mechanism, like “-all”, could lead to immediate rejection of emails. This rejection occurs early in the email handling process, even before any DMARC processing takes place.
Therefore, if an email sender’s SPF policy includes a “-all” mechanism, indicating a strict policy to reject emails that fail SPF checks, it could result in message rejection before any DMARC policies or processing occur. This early rejection can happen regardless of whether the email might eventually pass DMARC authentication.
Hence, under these circumstances, SPF Softfail triumphs over the Hardfail mechanism. It is a considerably low-risk approach that leaves room for review by simply flagging authorized emails instead of rejecting them.
Secure SPF Implementation Strategies
Optimal SPF implementation is essential for safeguarding email communication against unauthorized spoofing and phishing attacks. By following best practices, organizations can enhance their email security posture and protect their brand reputation. Here are some strategies and guidelines for implementing SPF securely:
1. Use an SPF Record Generation Tool
The SPF implementation process begins with record generation. You can create your record manually by having a proper understanding of SPF tags. This method is however prone to human errors. Ideally, you can use our automated SPF generator tool. This helps you create an error-free, accurate SPF record that is customized for your organization’s needs.
2. Use Appropriate SPF Mechanisms
Utilize SPF mechanisms such as “include,” “a,” and “IP4”, to specify the allowed sending sources. Be judicious in selecting mechanisms based on your email infrastructure and ensure they accurately reflect your email sending practices.
3. Maintain and Optimize Your SPF Record
Your Sender Policy Framework record needs to be maintained and optimized to prevent it from malfunctioning. SPF tends to break when your authorized senders exceed the 10 DNS lookup limit on the receiver’s side. To maintain an optimal lookup limit, our hosted SPF solution is your best bet! We help domain owners optimize SPF with a single click, to stay under lookup and void limits and maintain error-free SPF.
4. Combine SPF with DMARC
Deploying DMARC (Domain-based Message Authentication, Reporting, and Conformance) alongside SPF provides an additional (yet essential) layer of security. DMARC enables domain owners to specify email handling policies, including what action to take on emails that fail SPF.
DMARC has shown proven results in minimizing email fraud, compromise and impersonation attacks.
5. Implement Strict SPF Failure-Handling Policies
Configure your record to treat SPF authentication failures with strict policies, such as rejecting or marking emails from domains with failures. To do so, you can either implement SPF hardfail or SPF softfail instead of a neutral policy.
6. Monitor SPF Authentication Results
Implement DMARC reports to monitor SPF authentication results, such as SPF pass, and fail, as well as alignment errors. A DMARC analyzer tool can help you parse and analyze SPF authentication data in an organized, human-readable manner.
Final Words
There is no direct answer to the question “Which is better? SPF hardfail or softfail”. While the hardfail tag can provide you with better security, choosing the correct solution for monitoring your sending sources becomes crucial.
PowerDMARC’s advanced domain authentication and reporting platform provides comprehensive SPF and DMARC solutions for businesses of all sizes. Sign up today for a free trial!
Domain & Email Security Expert at PowerDMARC
Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.
Latest posts by Yunes Tarada (see all)
- BreakSPF Attacks: Outsmart the Hackers and Protect Your Email - November 13, 2024
- PowerDMARC Integrates with ConnectWise - October 31, 2024
- What is Datagram Transport Layer Security (DTLS): Benefits & Challenges - October 29, 2024
