There’s a constant online debate about which is better – SPF softfail or SPF hardfail. While the former is considered less secure, the latter has the risk of having even your genuine email conversations land in spam folders. This is because, at times, even genuine emails fail to pass spam filters and SPF authentication checks.
So, we have carefully curated this article to explain the major difference between these two mechanisms and why we recommend SPF softfail over hardfail. Please note that the term SPF hardfail is technically incorrect (as it’s formally referred a fail in RFC7208), but we will be using it throughout the content for better understanding and readability.
What is SPF Failure and its Types?
When an email is sent from an SPF-compliant domain, the recipient’s server checks if it’s actually sent by the sender it’s claiming to be coming from. This is done to abort phishing and spoofing attempts made in your business’ name.
The recipient’s server checks the sender’s authenticity by looking into the SPF DNS record enlisting all the IP addresses permitted to send emails from that particular domain. SPF failure occurs if the sender’s IP address isn’t included in the list. This means that the receiving server will consider your email as fraudulent or phish-y.
Now, there are 2 types of SPF failures.
What is SPF Softfail?
A softfail SPF failure type indicates the sender’s IP address isn’t probably permitted to send emails from your domain. You have to add an ~all mechanism at the end of all your SPF records. By applying this mechanism, you can be notified of SPF softfail status for all the emails failing verification checks.
“As per section 8.5 of RFC7208, A “softfail” result ought to be treated as somewhere between “fail” and “neutral”/”none”. The ADMD believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.”
SPF softfail Example
v=spf1 include:spf.example.outlook.com ~allIn this example, the tilde sign (~) next to ‘all ‘ represents a softfail SPF for IP addresses not mentioned in the TXT record. This instructs receiving mail servers to allow such emails, but they must be tagged as spam or suspicious.
What is SPF Hardfail?
SPF hardfail indicates that the sender’s email address is explicitly not permitted to send emails using the domain. It directs recipients’ servers to outrightly block such emails from entering the mailboxes.
Adding the -all mechanism at the end of your SPF record ensures only messages sent by trusted and permitted email senders land in recipients’ inboxes. Any fraudulent servers will trigger SPF to fail, and this issue will cause a hard bounce-back.
As per section 8.4 of RFC7208, A “fail” result is an explicit statement that the client is not authorized to use the domain in the given identity. Disposition of SPF fail messages is a matter of local policy.
SPF Hardfail Example
v=spf1 ip4:196.178.0.2 -allIn this example, the minus sign (-) next to ‘all’ represents an SPF hardfail, meaning emails from senders outside the list should be rejected. Here, only the IP address 196.178.0.2 will pass the SPF authentication check.
The Major SPF Flaw
There are multiple flaws in SPF’s working structure and the major one being that SPF authentication happens on the Return-Path/.mailfrom domain, not from the sender’s email address that most users usually see.
So, imagine a malicious actor using xyz@malicous.com as the .mailfrom domain and sending@amazon.com as the .From address.
In this situation, they have control of the .mailfrom domain (xyz@malicous.com). So, they will create an SPF record for the same, which permits this specific .mailfrom domain to send emails. So, phishing and spoofing emails will pass the SPF authentication checks, and recipients would be tricked into believing that messages have come from amazon.com (unless they check the .mailfrom domain name).
However, on the brighter side, a solution to this SPF flaw was developed when DMARC was introduced. One of the DMARC requisites is that the .mailfrom domain and .from domain should be the same. This makes threat actors incapable of bypassing email authentication protocol checks for phishing emails sent using your company’s official domain name.
How does the SMTP Relaying Break SPF?
Email relaying is an SMTP service that relays or forwards all incoming emails to another domain of the same company, and this is common for businesses having more than one domain. This simply means that it’s common for emails sent to Domain-1 to automatically get delivered to Domain-2 of the same company.
In this case, the SMTP service’s IP address won’t belong to the list included in the SPF record, and the email will fail SPF authentication, including the genuine one. You also need to understand that you can’t control or stop this from happening as relaying occurs at the recipient’s end. The only solution to this is using the +all mechanism, but you should never do that, as it will allow all emails to pass authentication checks.
Why DuoCircle Discourages the SPF Hardfail Mechanism?
We know that the SPF hardfail mechanism instructs the receiver’s server to reject the entry of emails failing SPF authentication checks outrightly. Also, SPF hardfail occurs at the SMTP level, which means the recipient’s server won’t evaluate the message further, and both DKIM and DMARC checks will be ignored too.
Also, emails undergoing relaying won’t show up in the recipient’s mailbox (not even in the spam folder), and in this case also, both DKIM and DMARC will be ignored. Even fully authentic email messages with an aligned DKIM signature get rejected if you have applied the -all mechanism.
Even section 10.1 of RFC7489 apprises the same situation- “Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a “-” prefix on a sender’s SPF mechanism, such as “-all,” could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use “-all” should be aware of this.”
Some users say that they use SPF hardfail and never have a problem. It’s important to understand that if you use SPF with the hardfail mechanism and deploy DMARC, an email is rejected before the DMARC authentication process is performed. So, you may not receive a DMARC report for such emails and never get to know if they were rejected. Depending on the configuration of both your sending and receiving systems, you may or may not receive an NDR (non-delivery report/bounce report) upon a hard rejection.
Is Softfail Less Secure?
There’s no doubt that SPF isn’t self-sufficient and 100% reliable when it comes to protection against a number of phishing and email domain spoofing attack types. Thus, it must be paired with DKIM and DMARC policies.
Hackers can bypass SPF checks if you haven’t implemented DMARC, as it maneuvers how recipients’ mail servers handle SPF failures. So, SPF ‘hard’ fail (-), softfail (~), and even neutral (?) have the exact same effect when using DMARC.
If you use DMARC and SPF both, implementing the hardfail mechanism won’t make your domain less vulnerable to unauthorized use. This is because DMARC considers both softfail and hardfail the same. However, if we talk about them from the prospect of email deliverability rate, then SPF hardfail isn’t a good choice; it can even have legitimate emails bounce back.
Remember that SPF has a few flaws in its overall functioning, but it’s not deprecated and should definitely be considered an effective email authentication protocol.
Does the SPF Softfail Mechanism Depreciate Your Domain’s Reputation?
DuoCircle doesn’t have a definite answer to this question yet. All SMTP software implementations can slew from the standards to draw their own implementation of a reputation system that checks for the SPF policy. But it’s true that the deliverability issues due to the -all mechanism will prevail over the reputation benefits of obscure spam detection systems.
Deployment of DKIM and DMARC not only promotes the email deliverability rate but also outweighs SPF flaws. This provides receivers with enough information to trust you as a genuine sender and make an informed decision. All verified emails count towards the domain reputation and increase the rate.
When Should You Use the Hardfail Mechanism?
The hardfail mechanism should definitely be used for non-email-sending domains. The consequences for the email-sending domains are actually beneficial for non-email-sending domains as hackers can’t use them for attempting phishing attacks in your business’ name. It also applies to parked and relaying domains that are used for inbound emails and not outbound.
For all non-email-sending domains, a ‘block all’ SPF term, i.e., v=spf1 -all, when combined with a DMARC policy with p=reject, aborts any email from the domain to be deliverable.
DMARC is the Ultimate Solution to SPF’s Shortcomings
SPF has many shortcomings, and the implementation of DMARC outweighs them. It’s even better to focus on DKIM for optimum email security and deliverability. If your domain is DKIM and SPF aligned, it’s easier for DMARC to apply the quarantine or reject policy.
Please note that you require SPF and/or DKIM alignment to achieve DMARC alignment. So, focusing on achieving a 100% DKIM alignment assures DMARC alignment, and your domain doesn’t have to rely solely on SPF for email authentication.
Email platforms like Mailchimp and Postmark have stopped considering SPF alignment as one of the factors, and this leads to a 0% SPF alignment rate. New DMARC adopters get apprehensive about seeing this, but it’s absolutely fine as they consider DKIM for all emails.
Best Email Hardening Guide
- Use SPF softfail mechanism.
- Implement DMARC with the ‘none’ policy in the starting.
- Use the DMARC reports ensuring all designated senders are signing with DKIM, achieving DMARC DKIM alignment.
- Enable DKIM for all the senders.
- After DKIM alignment is achieved for all the senders, switch to DMARC quarantine or reject policy to avert delivery of impersonated emails.
Final Words
AutoSPF encourages SPF softfail over hardfail as the latter can cause email deliverability issues that you even fail to recognize if DMARC is also deployed. This is because you may not receive an NDR or Non-Deliverability Report upon a hard rejection.
However, we strongly recommend setting the SPF hardfail mechanism for non-email-sending domains.
Overall, the collective efforts of SPF, DKIM, and DMARC ensure optimum email security and averts phishing attacks attempted in your business’ name.
For further assistance and guidance, please reach out to us at support@duocircle.com.
