I learned the hard way what SPF really means. One Friday afternoon I switched our production domain from softfail to hardfail mode, completely forgetting about an events platform we'd set up months back. The emails just disappeared. That Friday taught me something critical: do you actually know every place your mail originates from, and are you prepared for the delivery fallout if you get it wrong?

Since then, I treat SPF changes the way pilots treat checklists—methodical, with safeguards, and never rushed.

Let me break down what's actually happening under the hood. SPF (sender policy framework) is a DNS-based email authentication system. You publish an SPF record as a DNS TXT record at your domain that tells receiving servers which hosts are allowed to send mail on your behalf. Those servers check your mechanisms (ip4, ip6, a, mx, include) and qualifiers, then produce a result: pass, none, neutral, softfail, hardfail, temperror, or permerror.

The key difference comes down to that terminal qualifier. A softfail (~all) says "this looks unauthorized, but proceed with caution." A hardfail (-all) says "only listed hosts are legitimate—block everything else." That single character changes how mailbox providers treat your messages.

Here's where it gets practical. With softfail, you typically see spam folder placement or quarantine. With hardfail, especially when DMARC alignment is in place, you can get outright rejection at the mail server. Microsoft 365 and Outlook tend to combine SPF with DKIM and content filters. Google and Yahoo lean heavily on DMARC and sender reputation. So a softfail might land in Promotions; a hardfail with DMARC alignment can mean decisive blocking.

I never jump straight to hardfail. My path is always: neutral (?all) → softfail (~all) → hardfail (-all). During discovery, when I'm uncertain about legacy email flows or vendor IP ranges, I use softfail. It flags domain misuse without tanking deliverability while I inventory every sending source—CRM, marketing automation, ticketing, HR, finance, even printers.

Once I've validated every authorized sender and DKIM is consistent everywhere, then I move to hardfail. The risk trade-off is real: softfail gives you better deliverability during inventory but higher risk that phishing slips past as spam instead of being blocked. Hardfail gives you stronger security but can break legitimate mail if you've missed a sender.

I've seen teams blow past the 10-DNS-lookup limit by over-nesting includes. I've seen them forget seasonal vendors like Livestorm or Prismic webhooks. And I've watched people assume DMARC will save a broken SPF record—it won't, not without alignment.

The real lesson: treat SPF, DKIM, and DMARC as a system, not isolated pieces. Forwarding breaks SPF because the connecting IP changes. If you're using SRS (Sender Rewriting Scheme), you're fine. If not, softfail might be all that prevents friendly fire. That's why I monitor DMARC aggregate reports obsessively and read Authentication-Results headers when something fails.

My safe rollout: map every mail server and workflow first, validate DKIM everywhere, enable DMARC at p=none for telemetry, move SPF to softfail and watch for two sending cycles, investigate every unauthorized sender, then dry-run a reject policy before flipping to hardfail.

Over the last couple years, Google and Yahoo have tightened authentication requirements. Policy enforcement is increasingly multi-signal: SPF mode, DKIM signatures, DMARC policy, content, and reputation all matter. That's why I never treat SPF in isolation. An SPF hardfail without solid DKIM can still backfire on deliverability if forwarding is common.

The biggest mistake I still see: teams flip to hardfail before DKIM is ubiquitous, or they rely on softfail forever while attackers adapt and email spoofing thrives in that ambiguity. It's a balance, but the path is clear if you're methodical about it.