SPF Softfail vs Hardfail: Which One to Publish

Google's Workspace admin help tells you to end your SPF record with ~all. Microsoft's Defender for Office 365 documentation tells you to end it with -all. Both pages describe the same two characters at the end of the same DNS record, both publish their reasoning, and they arrive at opposite recommendations.

Neither is wrong. They are answering the question for different domains, and the reason they diverge is the thing worth understanding before you copy either one onto yours.

The two characters, and what the specification says they mean

An SPF record is a list of mechanisms with an optional qualifier in front of each one. RFC 7208 defines four qualifiers, +, -, ? and ~, and the plus is what you get when none is written. The all mechanism sits at the right-hand end and always matches, which is what makes it the default verdict for every sender that did not match anything earlier in the record. The specification is blunt about position: any mechanism listed after all must be ignored.

So ~all and -all are the same instruction with different confidence attached. The specification defines each result in one sentence.

A fail, which is what -all produces, is defined as "an explicit statement that the client is not authorized to use the domain in the given identity."

A softfail, which is what ~all produces, is defined more carefully as "a weak statement by the publishing ADMD that the host is probably not authorized." The same section adds that a domain publishing one has not gone on to publish the stronger, more definitive policy that would produce a fail.

ADMD there means the administrative management domain, which is you. Read the two definitions side by side and the distinction is not about severity of punishment. It is about how complete you are claiming your own record is. A hard fail asserts that every legitimate sender for the domain is listed. A soft fail asserts that you believe unlisted senders are unauthorised and are not prepared to stake delivery on it.

~all, softfailA weak statement

• Says the host is probably not authorised
• Concedes that the record may be incomplete
• Receiving software is told not to reject on this result alone
• Survives a sender you forgot to list
• Leaves the disposition to the receiver's own filtering

-all, hardfailAn explicit statement

• Says the client is not authorised to use the domain
• Claims the record is complete
• Permits rejection during the SMTP conversation
• Breaks a sender you forgot to list
• Gives the sending side an immediate bounce

What a receiver is actually obliged to do

This is the part that changes how the whole decision should be read, and it is stated in the specification before any of the result definitions: "the protocol establishes no normative requirements for handling any particular result."

Nothing you publish at the end of an SPF record compels a receiving mail server to do anything. The qualifier is a declaration of your confidence, and the receiver decides what that declaration is worth.

The specification does offer guidance, and the two results are treated differently. For a softfail it says that "Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal." For a fail it leaves the disposition to local policy, notes that rejecting during the SMTP transaction conserves bandwidth and gives the sender immediate feedback, and adds that "SPF-based rejection does present some risk of rejecting legitimate email" when the rejection rests on the envelope sender.

That risk is not hypothetical. It is the forwarding problem, and the specification devotes an appendix to it. When a message is forwarded by a mailing list or a redirect, the forwarding host sends from its own address while keeping your domain in the envelope, so your record does not authorise it and the check fails. Softfail exists in the protocol largely because of this class of legitimate mail.

The two providers, and why they disagree

Google's admin help for a Workspace SPF record states plainly: "Google recommends you use ~all in your SPF record." The same page explains what the tag does, saying the ~all tag tells receiving servers to mark messages as spam if they come from servers that are not listed in the record.

Microsoft's documentation for configuring SPF says the opposite, and gives its reasoning in the same breath: "For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain."

The rest of Microsoft's argument is the interesting part, because it is a claim about DMARC rather than about SPF. The page states that "DMARC treats -all (hard fail) and ~all (soft fail) as SPF failures", which is to say the qualifier makes no difference to whether a DMARC evaluation records an SPF pass. It then adds the wrinkle: "But the DMARC policy is effectively ignored for SPF ~all failures if the messages don't also contain DKIM signatures." Its conclusion follows directly: "We recommend -all so DMARC can act on messages that fail SPF if the messages also lack DKIM signatures."

Put the two recommendations next to each other and the disagreement resolves into a difference of assumption. Google is advising a domain owner who is still discovering which services send as their domain, and it is optimising for not breaking their own mail. Microsoft is advising a tenant it expects to have DKIM and DMARC configured, and it is optimising for enforcement working end to end.

Both assumptions are correct for the domain each vendor has in mind. Neither is automatically correct for yours.

The cost of a hard fail that neither vendor page leads with

The updated DMARC specification, RFC 9989, published in May 2026, names a consequence of -all that is easy to miss and expensive to discover.

SPF is evaluated early in the SMTP conversation, before any message content has been transferred, and a receiver is free to act on that result before it has any reason to look at your DMARC policy. The specification spells out what follows. A hard fail prefix "could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place". It goes further and names the specific loss: "messages that might otherwise pass DMARC due to an aligned DKIM-Authenticated Identifier (Section 4.4.1) could be rejected solely due to an SPF fail".

DMARC is designed so that either authentication method can carry a message. As RFC 9989 puts it, a DMARC pass "requires not only an SPF or DKIM pass verdict" but also that the passing domain be aligned with the author domain. A -all record removes half of that redundancy for any receiver that enforces SPF standalone, because the message never survives to the point where its DKIM signature would have rescued it.

Then comes the part that matters most for anyone running outbound, because it is about diagnosis rather than delivery: "messages rejected early in the SMTP transaction will never appear in aggregate DMARC reports, as the transaction will never proceed to the DATA phase".

A rejection you cannot see is worse than a rejection you can. The whole reason to publish a DMARC record and collect reports is to find the senders you forgot about, and a hard fail can remove exactly those senders from the evidence you were collecting to find them. That is the mechanism by which a domain can look clean in aggregate reports while quietly losing mail.

1. Step 1MAIL FROM is offered

   The envelope sender arrives before any message content

2. Step 2SPF is evaluated

   Your record is checked against the connecting address

3. Step 3A hard fail permits rejection here

   The receiver may refuse the message during the SMTP conversation

4. Step 4DATA is never transferred

   The From header, and therefore your DMARC policy, is never reached

5. Step 5Nothing reaches the report

   The sender you needed to discover is absent from the aggregate feed

What this means for a sending domain

The decision is different for the two kinds of domain a B2B team owns, and running one policy across both is what produces the trouble.

Your primary company domain carries an open inventory. Invoicing, payroll, support, calendaring, a form on the website, an events platform somebody signed up for two years ago. You do not know the full list on the day you write the record, and the honest position is the one the specification describes: a weak statement, because a strong one would be a claim you cannot support. Stay on ~all while DMARC reports are still surfacing senders you had forgotten, and treat the arrival of a surprise sender as evidence the record is not yet complete.

A dedicated outbound sending domain is the opposite case. It exists to send from one platform, it carries one include: and one DKIM key, and its inventory is closed on the day it is provisioned. Nothing else has any business sending as it. That is the condition a hard fail assumes, and it is the only common situation where the assumption is true from the start rather than after a year of watching.

The argument for tightening those domains is the same argument that applies to the DMARC policy on them: a single-purpose domain gives you a fast, unambiguous alarm when something breaks, which is the reasoning set out in DMARC quarantine against reject. The argument against tightening them is the RFC 9989 blind spot above, and it has real weight while you are still proving the setup works.

The sequencing that respects both is to publish ~all on a new sending domain, run it until the reports show the platform authenticating cleanly and nothing else sending, and only then decide whether -all buys you anything. On a domain with one sender it usually buys very little, because the spoofing protection people reach for hard fail to get is what the DMARC policy is already providing.

One thing worth checking before either qualifier matters at all: a record that exceeds the ten-DNS-lookup budget returns a permerror rather than a verdict, and neither ~all nor -all is ever reached. The arithmetic behind that limit is in SPF records for cold email, and it is a more common cause of authentication failure than the closing qualifier is.

Ready to publish -all on this domain?

• ✓Yes: Every service that legitimately sends as this domain is listed in the record
• ✓Yes: DMARC reports have been arriving long enough to surface an occasional sender
• ✓Yes: The record resolves inside the ten-lookup limit, so a verdict is reached at all
• ✓Yes: DKIM signing is configured and aligned, so authentication has a second leg
• ✓Yes: Somebody owns the bounce feed and would notice a legitimate sender disappearing
• ✕No: This domain is still discovering which internal tools send as it
• ✕No: Mail from this domain is regularly forwarded by lists or redirects
• ~Depends: The domain is parked and sends nothing at all

The parked-domain case, where there is no argument

A domain you own and never send from has no inventory to get wrong. There is no legitimate mail to break, so the reason for a weak statement disappears, and a record asserting that nothing is authorised to send as it is simply accurate.

Teams buying domains in batches for outbound and activating only some of them are sitting on this case constantly. The unactivated ones are parked domains, and the cheapest correct thing to do is publish a record that authorises nothing until the day one goes into service. Microsoft's documentation carries a worked parked-domain record for exactly this, and the record is short because there is nothing to authorise.

Where the qualifier stops mattering

It is worth being clear about how much of this decision DMARC absorbs, because the answer is most of it.

Once a domain publishes an enforcing DMARC policy and both authentication methods are configured, the disposition of unauthenticated mail claiming your domain is being decided by that policy rather than by the SPF qualifier. Microsoft's own page says as much when it states that DMARC treats both qualifiers as SPF failures. The residual differences are the two named above: what a receiver that enforces SPF on its own does, and whether a rejection ever reaches your reports.

That is a narrow band, and it is the honest size of the question. Teams spend more time arguing about the last two characters of an SPF record than the decision deserves, while the full authentication set is where the delivery outcome is actually determined.

The short version

RFC 7208 defines -all as an explicit statement that an unlisted sender is not authorised and ~all as a weak statement that it is probably not authorised, and the difference is a claim about how complete your own record is rather than about how harshly anyone should be punished. The protocol imposes no handling requirement on receivers either way.

Google recommends ~all for Workspace domains. Microsoft recommends -all for Microsoft 365 domains, on the reasoning that it wants DMARC to act on messages that fail SPF and carry no DKIM signature. Both recommendations are correct for the domain each vendor is imagining.

The cost of a hard fail is set out in RFC 9989: a receiver may reject on SPF before DMARC processing happens, a message that would have passed on an aligned DKIM signature can be lost, and the rejection never appears in an aggregate report because the transaction never reaches DATA.

Publish ~all on a domain whose sender inventory is still open, publish it on a new outbound sending domain until the reports prove the setup, and reserve -all for a domain where the inventory is genuinely closed, which in practice means a single-purpose sending domain that has been watched or a parked domain that sends nothing.

We run sending domains, authentication and the reporting behind these decisions as part of our outbound engagements. You can see what a campaign would look like for your market.

Specification details are per RFC 7208 (April 2014) and RFC 9989 (May 2026); provider guidance is per Google Workspace admin help and Microsoft Defender for Office 365 documentation, both fetched on 2 September 2026. Verify current guidance at the source before making DNS changes.

Sources: RFC 7208, Sender Policy Framework, RFC 9989, DMARC, Google Workspace SPF guidance, Microsoft SPF configuration