SPF Softfail vs Hardfail: Which Policy Should You Use?

The choice between SPF softfail (~all) and hardfail (-all) is the difference between giving a mail server a suggestion and giving it a command. If you are currently auditing your email sources or frequently add new third-party tools, use softfail (~all). This ensures that if you miss a source, your mail is flagged as spam rather than deleted. If your infrastructure is locked down, fully audited, and you want to maximize protection against spoofing, use hardfail (-all).

However, in the modern era of email authentication, the qualifier you choose is increasingly secondary to your DMARC policy. While SPF defines who can send mail, DMARC defines what happens when those rules are broken.

The Mechanics of the SPF Qualifier

An SPF record is a single line of text in your DNS settings that lists authorized IP addresses and domains allowed to send email on your behalf. It always begins with the version tag v=spf1 and ends with a "catch-all" mechanism. This mechanism consists of a qualifier and the word all.

The qualifier tells the receiving mail transfer agent (MTA) how to treat any email that does not originate from the IP addresses or "includes" listed earlier in the record.

Softfail (~all)

Definition: The tilde (~) indicates a "Soft Fail." It tells the receiving server that the sender is likely not authorized, but the server should not reject the message outright. Receiver Action: Most major providers, such as Gmail or Outlook, will accept the email but increase its "spam score." This usually results in the email being delivered to the Junk or Spam folder. Best For: Testing phases, organizations with decentralized IT, or when using email forwarding services that might break SPF.

Hardfail (-all)

Definition: The hyphen (-) indicates a "Hard Fail." This is an explicit instruction that any sender not listed in the record is unauthorized. Receiver Action: The receiving server is instructed to reject the email during the SMTP transaction. The message is never delivered to the recipient's inbox or spam folder. Instead, the sending server receives a 550 permanent rejection error. Best For: Fully audited domains, high-security environments, and domains that do not send email at all (parked domains).

Why the Choice Matters for Deliverability

The primary risk of a hardfail policy is "false positives." If you use a service like Zendesk, Mailchimp, or a specialized payroll tool and forget to include their specific SPF mechanism in your DNS record, a hardfail policy will cause every single one of those legitimate emails to bounce.

Conversely, the risk of a softfail policy is "spoofing." If a malicious actor attempts to send a phishing email appearing to come from your domain, a softfail policy makes it more likely that their email will reach the recipient's spam folder—where a curious user might still click a malicious link—rather than being blocked at the gateway.

To understand the foundational role of these records, you should first understand what is an spf record? and how it serves as the first line of defense.

Comparing Softfail and Hardfail

Because the site cannot render tables, the following breakdown highlights the operational differences between the two policies.

Policy: Softfail (~all)

Label: Technical Intent Non-authoritative "Warning" to the receiving server. Label: Impact on Legitimate Mail High deliverability; even if the SPF record is missing a source, the mail usually arrives in the spam folder. Label: Impact on Spoofed Mail Moderate; spoofed mail may still reach the user's spam folder. Label: DMARC Interaction Results in an spf=softfail result, which DMARC interprets as a "fail."

Policy: Hardfail (-all)

Label: Technical Intent Authoritative "Instruction" to the receiving server. Label: Impact on Legitimate Mail High risk; any missing source in the SPF record results in a total bounce (550 error). Label: Impact on Spoofed Mail Maximum; unauthorized mail is rejected at the connection level. Label: DMARC Interaction Results in an spf=fail result, which DMARC interprets as a "fail."

The 10-Lookup Limit: The Silent Killer of Hardfail

Regardless of whether you choose softfail or hardfail, your SPF record is subject to a strict DNS lookup limit. The SPF specification (RFC 7208) dictates that a single SPF check must not result in more than 10 DNS lookups.

Every time you use an include: statement, such as include:_spf.google.com or include:spf.protection.outlook.com, you are consuming lookups. If your record is complex and exceeds this limit, the receiving server will return a "PermError."

In the event of a PermError, the qualifier (~all or -all) is ignored because the record itself is considered invalid. This is why it is critical to use email tools to validate your record's lookup count before moving to a stricter policy. If you are over the limit, your "hardfail" policy won't protect you; it will simply invalidate your entire authentication setup.

The Role of DMARC in the Softfail vs Hardfail Debate

In the past, the SPF qualifier was the final word on how an email was handled. Today, DMARC (Domain-based Message Authentication, Reporting, and Conformance) has largely superseded the SPF qualifier's authority.

DMARC allows a domain owner to specify a policy (p=none, p=quarantine, or p=reject) that applies if an email fails both SPF and DKIM checks.

1. If you have a DMARC policy of p=reject: It almost doesn't matter if you use ~all or -all. If the SPF check fails, DMARC will see that failure and trigger the rejection based on the DMARC policy, not the SPF qualifier.
2. The "Safe" Transition: Most security experts recommend using SPF ~all combined with a DMARC policy that gradually moves from p=none to p=reject. This allows you to receive reports on who is sending mail on your behalf without risking a total communication blackout.

If you are ready to move beyond basic SPF, you should learn how to build a dmarc record to take full control of your domain's reputation.

Google and Yahoo’s 2024 Requirements

Starting in 2024, Google and Yahoo implemented strict requirements for bulk senders (those sending more than 5,000 messages a day to their users). These requirements mandate that senders have both SPF and DKIM in place.

While these providers do not explicitly require -all, they do require that your authentication "aligns." If you use ~all, you are technically compliant, but if your SPF fails and you lack a valid DKIM signature, your mail will be rejected regardless of the tilde. The industry is moving toward a "strict alignment" model where "soft" policies are viewed as temporary testing states rather than permanent configurations.

How to Audit Your Record Before Switching to Hardfail

Before you change your record from ~all to -all, follow these steps to prevent a self-inflicted denial-of-service on your own email:

1. Analyze DMARC Reports: Use a reporting tool to see every IP address currently sending mail using your domain.
2. Identify "Shadow IT": Look for marketing, HR, or sales tools that might be sending automated notifications that you weren't aware of.
3. Check for Forwarding: If your users frequently forward their work email to personal accounts (like Gmail), SPF will fail because the forwarding server's IP is not in your record. In these cases, DKIM is required to maintain authenticity.
4. Verify the 10-Lookup Limit: Ensure your record isn't already broken by too many include statements.
5. Test with a Subdomain: If you are nervous, apply the -all policy to a non-critical subdomain first to see if any unexpected bounces occur.

When to Use Other Qualifiers

While ~all and -all are the most common, two other qualifiers exist in the SPF specification, though they are rarely recommended for modern production environments.

Neutral (?all)

The question mark indicates that no policy is stated. It essentially tells the receiver, "I have an SPF record, but I'm not making any claims about whether other senders are authorized or not." This is functionally similar to not having an SPF record at all and is generally only used during very brief testing windows.

Pass (+all)

The plus sign indicates that any sender is authorized. This effectively turns off SPF protection entirely. You should never use +all on a live domain, as it explicitly tells the world that anyone can spoof your email and pass SPF checks.

Final Recommendation

For 90% of organizations, SPF Softfail (~all) is the correct choice when paired with a DMARC policy of p=quarantine or p=reject. This configuration provides the security of DMARC enforcement while allowing for the slight technical "fuzziness" that occurs with email forwarding and complex routing.

Only move to Hardfail (-all) if you have a specific compliance requirement or if you are protecting a domain that is a frequent target of high-volume phishing attacks and you have verified every single mail source.

FAQ

Does SPF hardfail improve my sender reputation?

Not directly. While it shows you have a strict security posture, mailbox providers like Gmail care more about whether your mail is wanted by users. However, preventing spoofing via hardfail protects your reputation from being damaged by "backscatter" or spam sent by others in your name.

Why do some experts say softfail is better for DMARC?

Because of email forwarding. When an email is forwarded, the SPF check usually fails because the forwarding server is not an authorized sender for the original domain. If you use hardfail, the message might be dropped immediately. If you use softfail, the receiver might look at the DKIM signature instead, allowing the forwarded message to pass DMARC.

Can I have multiple SPF records if I need both softfail and hardfail?

No. A domain must only have one SPF record. If a DNS query returns multiple SPF records, the receiving server will return a PermError and ignore all of them. You must combine all your authorized sources into a single record ending in one qualifier.

What happens if I leave the qualifier out?

If you simply write v=spf1 include:spf.protection.outlook.com all, the default qualifier is "Pass" (+). This means your record will effectively authorize the entire internet to send mail on your behalf. Always ensure you include either the - or ~ before all.

If you are managing multiple domains and need to verify their status quickly, using a dedicated suite of email tools can save hours of manual DNS lookups and prevent costly configuration errors. Services like Best-TempMail often highlight the importance of these configurations for maintaining high-integrity communication channels. Using Best-TempMail as a benchmark for clean, temporary communication can help you understand how receiving servers treat different levels of authentication. Proper SPF configuration is the first step in ensuring your domain remains trusted by the global email ecosystem.