SPF Softfail vs Hardfail: Which to Use? | DMARCguardSkip to main content<br>18 min readShare

SPF Softfail vs Hardfail: A Data-Backed Decision Guide<br>53.6% of SPF-enabled domains use SPF softfail (~all). 40.2% use hardfail (-all). Google recommends one. Microsoft recommends the other. Who is right?<br>The choice between SPF softfail and hardfail is a configuration decision that email administrators face on every domain they manage. The two largest mailbox providers give contradictory advice, and the consequences affect email deliverability for every message you send.<br>This guide resolves the debate with first-party data from our scan of 5.5 million domains, documented receiver behavior at Google, Microsoft, and Yahoo, and direct citations from the RFCs that define how Sender Policy Framework (SPF) works. By the end, you will know which qualifier to use, why, and how to migrate if you need to change.

SPF softfail and hardfail produce different outcomes without DMARC, but identical results when DMARC is deployed.What Is SPF Softfail (~all)?<br>SPF softfail is the result returned when a sending IP address does not match any mechanism in the domain’s SPF record, and the record ends with the ~all qualifier. The SPF softfail meaning is specific: the ~ qualifier tells receiving mail servers that the sender is “probably not authorized” but asks them not to reject the message outright.<br>RFC 7208 Section 8.5 defines the softfail result precisely: receivers “SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny.” In practice, this means the message is accepted but may be routed to the spam folder based on additional signals.<br>An SPF record with softfail and the resulting email headers:<br>SPF Softfail Record plaintext

v=spf1 include:_spf.google.com include:sendgrid.net ~all

When a receiving server evaluates this record and the sending IP does not match, the email headers show:<br>SPF Softfail Email Headers email

Received-SPF: softfail (google.com: domain of user@example.com<br>does not designate 198.51.100.5 as permitted sender)<br>Authentication-Results: mx.google.com; spf=softfail smtp.mailfrom=example.com

The Received-SPF: softfail header and the spf=softfail entry in Authentication-Results both indicate the same outcome. The message was not rejected — the receiver accepted it and applied additional scrutiny.<br>Softfail became the industry default during SPF adoption because it preserves email deliverability for misconfigured senders. A missing include: mechanism results in spam-folder placement rather than outright rejection, giving administrators time to diagnose and fix the issue.<br>What Is SPF Fail (Hardfail) with -all?<br>SPF hardfail is the result returned when a sending IP does not match any mechanism in the domain’s SPF record, and the record ends with -all. The - qualifier is what RFC 7208 Section 8.5 calls an “explicit statement” that the IP is not authorized to send email for the domain.<br>Unlike softfail, the SPF fail result gives receivers stronger grounds to reject the message. However, the RFC does not mandate rejection — it states that disposition is “a matter of local policy.” Different receivers handle hardfail differently:<br>Google explicitly warns against hardfail: “A hyphen can be overly restrictive and cause delivery issues for legitimate email” (Google SPF setup guide).<br>Microsoft’s Exchange Online Protection has an optional “SPF Hard Fail” ASF toggle that is off by default. Microsoft itself advises against using this toggle, recommending DMARC instead.<br>RFC 7208 establishes no comprehensive normative requirement for handling any particular SPF result. Local policy decides.<br>An SPF record with hardfail and the resulting headers:<br>SPF Hardfail Record plaintext

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

SPF Hardfail Email Headers email

Received-SPF: fail (google.com: domain of user@example.com<br>does not designate 198.51.100.5 as permitted sender)<br>Authentication-Results: mx.google.com; spf=fail smtp.mailfrom=example.com

There is a critical operational difference that is often overlooked. As Al Iverson of Spam Resource points out, messages rejected at SMTP due to SPF hardfail never appear in DMARC aggregate reports . The domain owner cannot see the damage. With softfail, those messages at least reach the spam folder and show up in reporting — giving you visibility into what failed and why.<br>All Four SPF Qualifiers Explained<br>SPF defines four qualifiers in RFC 7208 Section 4.6.2. Each qualifier is a single character prepended to the all mechanism, and each tells receivers something different about unauthorized senders.<br>QualifierSyntaxSPF ResultReceiver ActionRecommendationPass+allPassAccept (all IPs authorized)Never use for sending domainsFail (Hardfail)-allFailMay reject outrightUse for parked/non-sending domainsSoftfail~allSoftfailAccept, apply scrutinyRecommended for sending domainsNeutral?allNeutralNo assertion madeAvoid (except DMARC-only setups)

SPF Qualifier...