Sender Policy Framework, or SPF, is a simple way to tell the receiving servers which IPs or mail servers are allowed to send emails on behalf of your domain. It basically means ‘allowlisting’ all those who are officially permitted to send emails as your business representatives. But that’s not all when it comes to implementing SPF. A mere list of all the authorized senders is not enough!
What happens when one of your emails gets forwarded? Or when a third-party service you forgot to include tries to send on your behalf? That’s where the complexities come in! When you create and publish an SPF record in the DNS, you also need to set rules for how recipients should handle emails that come from senders not on your approved list.
The good thing is SPF gives you the flexibility to decide what happens next. Either you can let those emails through with a SoftFail (~all), which flags them as suspicious but doesn’t block them, or you can reject them outright with a HardFail (-all).
If you want a stricter approach for your failed emails, HardFail is the way to go. But you can’t jump right into it; you must move gradually from SoftFail to HardFail. Let us take a look at how, but before that, let us take you through the basics.
What is SoftFail?
When you set up SPF for your domain, you identify which servers can send emails on your behalf. Along with listing these servers, you also identify how email systems should react to messages that originate from unauthorized sources.
If your SPF record ends with ~all, that means you’re using what’s called a SoftFail. This mode tells the receiving mail servers that any email coming from a server not on the list is probably unauthorized, but they shouldn’t reject it entirely. Instead, the message can be delivered but flagged as suspicious or filtered into the recipient’s spam folder.
Since it is a relatively lenient setting, it is used during the initial stages of SPF implementation. As a domain owner, with SoftFail (~all) in place, you can keep an eye on what’s going on with your domain, how it is being used, that too, without disrupting any email delivery.
So, when you send an email from an IP address that is not listed on your SPF record, the recipient’s server then refers to the ~all tag. Once the receiving server identifies that you have set the result qualifier to SoftFail, it lets the message in but doesn’t treat it as fully trusted. Instead, it marks it as suspicious and delivers it into the spam folder.
This approach is especially useful in cases where there are multiple systems or third-party services sending emails on your behalf, and you’re still in the process of identifying and authorizing all of them.
What is HardFail?
If you want to tighten the security of your domain’s email infrastructure, HardFail is one of the strictest qualifiers you can apply within your SPF. HardFail is set by ending your SPF record with -all, which clearly states that only servers that you have explicitly specified are allowed to send emails on your behalf; everything else should be outright rejected.
If an incoming email does not pass the SPF check—i.e., it was sent by a server not included in your SPF record—and your qualifier is HardFail, the receiving mail server is told to reject the message. This will cause the mail not to be delivered at all, not even to the spam folder.
HardFail is a strict qualifier, which means that even though it blocks out certain emails that it finds suspicious, it also protects you against attackers who try to send fake emails using your domain. This can prove to be both good and bad. On one hand, you get stronger protection, but on the other hand, the chances of even legitimate emails getting blocked also increase significantly. It inevitably takes a toll on your email deliverability.
This is why you should be very careful while implementing HardFail and only move to it after thorough preparation and testing.
How do you seamlessly move from SoftFail (~all) to HardFail (-all) without breaking email deliverability?
Striking a balance between security and deliverability is not so easy, especially when grave cybersecurity threats are perpetually looming over your digital landscape. But there’s a way to do it, a way to ensure that your domain is well-protected and your audience receives the emails they’re supposed to.
Let’s see how you can strike this balance with SPF:
Start with a SoftFail (~all)
When you’re setting up SPF, you should start by implementing a SoftFail mechanism. This setting is more like a warning mode wherein you tell the receiving servers that the listed sources are authorized to send emails on your behalf—but if a message comes from somewhere else, it shouldn’t be blocked outright. This way, the legitimate emails would still reach the recipient’s mailbox, particularly in cases where you missed adding an address to the record.
Turn on DMARC in ‘monitoring’ mode
As you know, SPF alone is not enough; you need DMARC to make the most of each authentication policy. When you transition from SoftFail (~all) to HardFail (-all), make sure that your DMARC policy is enabled, at least at p=none. This won’t affect email delivery but will give you reports showing which servers are sending emails using your domain—and whether they’re passing SPF or DKIM checks. Looking at these reports, if you think anything’s missing, update your record accordingly.
Finally, move to HardFail (-all)
Once everything looks good, no legitimate emails are failing SPF, and there are no unexpected failures, you can change ~all to -all. This ensures that only authorized servers can send emails, helping block spoofing attempts without affecting legitimate communication.We understand that configuring SPF can be tricky, especially when your email deliverability is at stake. But guess what? You don’t have to do it all by yourself. Our team at AutoSPF can help you with everything related to SPF. Reach out to us today to learn more!
