SPF Softfail vs Fail: Pick the Setting That Won’t Backfire

What SPF is (and isn’t): stop blaming the wrong tool

SPF (Sender Policy Framework) answers one narrow question: is this IP allowed to send mail using this domain in the SMTP MAIL FROM / return-path?
That’s it. It doesn’t authenticate your “From:” header directly. It doesn’t certify the human identity of the sender. And it
definitely doesn’t stop a phisher from putting your CEO’s name in the display name field.

SPF is an authorization check performed by the receiver, based on the sender’s IP and DNS. The receiver evaluates the SPF record for the domain in the
envelope sender (the bounce address), not the visible From: header. DMARC is the layer that ties SPF (and/or DKIM) to the From: domain via alignment.

The core SPF result codes you actually see

• pass: the sending IP is authorized.
• fail: explicitly not authorized (typically from -all).
• softfail: not authorized, but “maybe” (typically from ~all).
• neutral: no assertion (often from ?all or ambiguous mechanisms).
• none: no SPF record found.
• temperror: transient problem (DNS timeout, SERVFAIL).
• permerror: permanent evaluation failure (syntax error, too many DNS lookups).

The operational gotcha: receivers handle these results differently. SPF is not a universal “reject switch.” It’s a signal.
Some systems treat softfail nearly like fail; others treat fail as a strong spam indicator but still deliver. You’re not controlling the receiver.
You’re controlling how defensible your signal is.

Paraphrased idea from Gene Kranz: “Tough and competent.” That’s the posture you want for email authentication: strict where it helps, careful where it breaks.

~all vs -all: what they mean, how receivers actually treat them

The last mechanism in most SPF records is an “all” qualifier. It’s your default policy for anything not matched earlier.
These two are the ones you’re choosing between:

• ~all (softfail): “Not authorized, but don’t be harsh.” Receivers often accept but mark or score.
• -all (fail): “Not authorized. This is explicitly wrong.” Receivers may reject, quarantine, or heavily score.

Receiver behavior: the uncomfortable truth

SPF fail does not guarantee rejection. SPF softfail does not guarantee delivery. Receivers combine SPF with reputation, content scanning,
DKIM, DMARC, ARC, historical sender behavior, and sometimes whatever their threat intel vendor sold them this quarter.

Here’s the practical difference you can count on: -all makes your intent unambiguous. If a receiver wants to use SPF as a decisive signal,
you’ve given them permission. With ~all, you’ve left wiggle room—and attackers love wiggle room.

The two big failure modes

1. False negatives (you block your own legitimate mail).
   Common causes: vendor senders not listed, SaaS platforms that rotate IPs, “scan-and-send” gateways, CRM tools, ticketing systems, and
   the classic: “we changed outbound mail routing and forgot SPF.”
2. False positives (attackers get a softer landing).
   With ~all, unauthorized sources are still “soft” failures. Many receivers will deliver but spam-folder it. Some will deliver to inbox if other signals look okay.
   That’s not a win.

Joke #1: SPF is like a bouncer with a clipboard. If the list is wrong, the VIP gets bounced and the troublemaker walks in wearing a fake mustache.

My opinionated recommendation (and when to break it)

Default recommendation: move to -all once you have inventory and monitoring

If you control your outbound mail and you can list every legitimate sender, use -all.
Softfail is fine as a transitional state, not a destination. Attackers don’t need your permission to send; they need your ambiguity to avoid hard filtering.

That said, you don’t “flip to -all” as a vibe. You do it when:

• you have a complete list of outbound sources (MTAs, relays, SaaS senders, helpdesk, marketing, payroll, monitoring tools),
• you can test SPF evaluation from multiple vantage points,
• you’re not consistently hitting SPF permerrors (lookup limit),
• you have DMARC reporting and you actually read it,
• you have a rollback plan (DNS TTL discipline, change control).

When ~all is justified

Use ~all temporarily if any of these are true:

• You’re still discovering senders and you don’t have DMARC reports yet.
• Your business relies on forwarders or mailing lists where SPF breaks and you don’t have DKIM alignment coverage.
• You inherited a domain with unknown “shadow IT” senders and you need a safe window to inventory without silently dropping critical mail.

The catch: a “temporary” ~all has a habit of becoming permanent. Put a date on it. Put an owner on it. If you can’t, you’re choosing drift.

When you should avoid both and fix the bigger issue

If you’re trying to use SPF policy to solve spoofing of the From: header, you’re holding the wrong wrench.
That’s DMARC’s job (with DKIM doing most of the heavy lifting for forwards). Your SPF record should be accurate and strict,
but the anti-spoofing strategy is SPF + DKIM + DMARC, not SPF alone.

Facts and history: why SPF behaves like this

• SPF emerged in the early 2000s as operators tried to curb forged envelope senders and reduce backscatter from bounces.
• SPF evaluation is tied to SMTP’s envelope (MAIL FROM / return-path), not the visible From: header humans see.
• The 10 DNS lookup limit exists because early SPF evaluation could hammer DNS and become a denial-of-service vector.
• ptr mechanism was effectively deprecated in practice because it’s slow, fragile, and can be abused via DNS control.
• SPF breaks on forwarding by design: the forwarder changes the sending IP but usually doesn’t rewrite the return-path to a domain it controls.
• DKIM was introduced partly because of forwarding: a cryptographic signature survives transit if intermediaries don’t modify signed headers.
• DMARC arrived later to connect authentication results to the visible From: domain and provide policy and reporting.
• ARC (Authenticated Received Chain) exists because strict DMARC can break legitimate forwarded flows (lists, gateways), and receivers wanted a way to trust intermediaries.
• Large receivers treat authentication as reputation input rather than a binary gate, because attackers adapt quickly and false positives are expensive.

Fast diagnosis playbook: find the bottleneck in minutes

When mail delivery goes weird after an SPF change, you need to stop guessing. Here’s the order that finds the problem quickly.

First: confirm what SPF record the world is seeing

• Query authoritative-ish resolvers (not just your laptop’s cached view).
• Confirm there is exactly one SPF TXT record (or at least not multiple “v=spf1” records).
• Check TTL; you may be chasing propagation ghosts.

Second: confirm what IP is actually sending

• Use a sample message’s Received headers to identify the connecting IP to the recipient.
• Don’t confuse internal hops with the external handoff IP.
• Verify whether the vendor sends directly or through your relay.

Third: evaluate SPF and count DNS lookups

• Run an SPF evaluator (or parse logs if you’re a receiver).
• Look for permerror (too many lookups) or temperror (DNS failures).
• Check includes and redirects; they’re lookup multipliers.

Fourth: check DMARC alignment and DKIM coverage

• If the failure is “spoofing,” DMARC is the policy control.
• If the failure is “forwarding,” DKIM alignment is your lifeline.
• If you have DMARC enforcement without DKIM coverage, you built a trap for yourself.

Fifth: decide the immediate action

• If business mail is blocked: rollback SPF change (or temporarily soften) and open an incident to inventory senders properly.
• If spoofing is getting through: tighten SPF to -all and move DMARC toward quarantine/reject once DKIM is stable.
• If permerror: reduce lookups, flatten, or move senders behind a controlled relay.

Practical tasks: 12+ commands, outputs, and decisions

These are not “nice to have.” These are the knobs you turn at 2 a.m. when Sales says the quote emails vanished.
Each task includes: command, what the output means, and the decision you make.

Task 1: Fetch the SPF TXT record (and spot duplicates)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"
"google-site-verification=abc123"

Meaning: One SPF record exists (good). The other TXT is unrelated. If you see two separate strings starting with v=spf1,
many receivers will treat that as a permerror.

Decision: If duplicates exist, merge into one SPF record immediately.

Task 2: Check the record as seen by specific resolvers (propagation sanity)

cr0x@server:~$ dig @8.8.8.8 +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Meaning: Public resolver sees the intended value.

Decision: If different resolvers disagree, don’t “fix” SPF again—wait for TTL or identify split-horizon DNS issues.

Task 3: Check TTL to estimate how long the blast radius lasts

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.        3600    IN      TXT     "v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Meaning: TTL is 3600 seconds. Worst-case caches hold old data about an hour.

Decision: Before major SPF changes, lower TTL a day ahead; during incidents, set expectations based on TTL reality.

Task 4: Verify the sending IP from a received message header (sender truth serum)

cr0x@server:~$ grep -iE '^(received: from|authentication-results:)' sample.eml | head
Received: from outbound.vendor.example (outbound.vendor.example [198.51.100.77])
Authentication-Results: mx.receiver.example; spf=softfail (example.com: domain of bounce@example.com does not designate 198.51.100.77 as permitted sender)

Meaning: The receiver evaluated SPF for example.com and the connecting IP was 198.51.100.77.

Decision: If that IP isn’t in your SPF, either add the vendor’s mechanism/include or route them through your authorized relay.

Task 5: Evaluate SPF with a local tool (quick and blunt)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounce@example.com -helo outbound.vendor.example
fail

Meaning: For the envelope sender domain, that IP is not authorized.

Decision: Don’t change -all to ~all to “fix” this. Fix the authorization list or the sending path.

Task 6: Count DNS lookups risk with an SPF inspection (detect permerror candidates)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.a.example include:_spf.b.example include:_spf.c.example include:_spf.d.example -all"

Meaning: Each include can trigger multiple lookups. You can hit 10 quickly.

Decision: If you’re approaching complexity, consolidate senders behind a relay or flatten carefully (see Task 9/10).

Task 7: Detect an SPF permerror (too many DNS lookups) via receiver logs (Postfix example)

cr0x@server:~$ sudo grep -i spf /var/log/mail.log | tail -5
Jan  4 11:02:18 mx postfix/smtpd[22190]: NOQUEUE: reject: RCPT from unknown[203.0.113.55]: 550 5.7.1 SPF permerror; too many DNS lookups; from=<bounce@example.com> to=<user@receiver.example> proto=ESMTP helo=<sender.example>

Meaning: SPF evaluation failed permanently. Some receivers reject on permerror, others treat as neutral; either way, it’s sloppy.

Decision: Reduce includes/redirects. Treat permerror as an outage condition for deliverability.

Task 8: Confirm you didn’t publish two SPF records (classic self-own)

cr0x@server:~$ dig +short TXT example.com | grep -c '^"v=spf1'
2

Meaning: Two SPF records exist. Many receivers return permerror.

Decision: Merge immediately into one record. Then re-check with multiple resolvers.

Task 9: Extract and validate include targets (are you depending on a broken vendor?)

cr0x@server:~$ dig +short TXT _spf.vendor.example
"v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.128/25 -all"

Meaning: Vendor publishes a clean SPF with explicit IP ranges and -all.

Decision: If vendor’s SPF is malformed or bloated, push back: either they fix it or you route through a controlled relay.

Task 10: Check SPF redirect usage (and understand its blast radius)

cr0x@server:~$ dig +short TXT mail.example.com
"v=spf1 redirect=example.com"

Meaning: Subdomain SPF is fully delegated to the apex policy.

Decision: If you need different senders for subdomains (marketing vs transactional), avoid redirect and define explicitly.

Task 11: Verify DKIM is present for a sender that will be forwarded (SPF-proofing)

cr0x@server:~$ grep -i '^dkim-signature:' sample.eml | head -1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

Meaning: Message is DKIM-signed by example.com. This can survive forwarding, preserving DMARC alignment even when SPF fails.

Decision: If forwarded mail is critical, prioritize DKIM correctness over trying to “make SPF work” through forwarders.

Task 12: Query DMARC policy (because SPF strictness alone isn’t the point)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Meaning: DMARC is enforcing quarantine and requires strict alignment for both DKIM and SPF.

Decision: If you don’t have strong DKIM coverage across all legitimate senders, strict alignment plus SPF fail can cause user pain. Fix sender configs first.

Task 13: Check alignment symptoms in Authentication-Results

cr0x@server:~$ grep -i '^authentication-results:' sample.eml | head -1
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=fail header.from=example.com

Meaning: SPF passed for bounce.example.com, DKIM passed for example.com, but DMARC failed for header.from=example.com.
That’s alignment mismatch: the domains aren’t aligned per your DMARC settings.

Decision: Align envelope sender domain with From domain (or relax alignment) and ensure DKIM uses the From domain where possible.

Task 14: Identify who is sending for you (Postfix outbound logs example)

cr0x@server:~$ sudo grep -E 'status=sent|relay=' /var/log/mail.log | tail -5
Jan  4 10:55:01 mta postfix/smtp[21011]: 1A2B3C4D: to=<user@outside.example>, relay=aspmx.l.google.com[142.250.102.27]:25, delay=1.2, status=sent (250 2.0.0 OK)
Jan  4 10:56:44 mta postfix/smtp[21022]: 5E6F7A8B: to=<user@outside.example>, relay=mail.protection.outlook.com[52.101.73.5]:25, delay=0.9, status=sent (250 2.6.0 Queued mail for delivery)

Meaning: You can see outbound destinations, but also infer if you’re sending directly or relaying through a smart host.

Decision: If you’re routing through a single relay, SPF can be simpler (authorize the relay). If you’re sending from many IPs, inventory is mandatory.

Task 15: Sanity-check your outbound public IP (cloud NAT surprises)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.55

Meaning: This host’s egress IP is 203.0.113.55 from the internet’s perspective.

Decision: Ensure that IP (or NAT range) is authorized in SPF if it can send mail directly. If IP changes, stop sending directly; use a stable relay.

Three corporate mini-stories from the trenches

1) Incident caused by a wrong assumption: “The vendor uses our relay”

A mid-sized company had an internal SMTP relay and a tidy SPF record: one IP range, one include, -all.
They also had a new HR platform that sent onboarding emails. Everyone believed the platform was configured to send through the relay.
It even said “SMTP configured” in the admin UI, which is a sentence that has misled more people than any phishing email ever has.

The first symptom wasn’t a bounce. It was silence. New hires didn’t get their onboarding links, managers didn’t get approvals,
and the HR team assumed it was “the app being flaky.” Meanwhile, a few external recipients did receive the messages—but in spam.
Different receivers, different behavior. That’s SPF life.

When someone finally pulled a raw message, the connecting IP belonged to the vendor’s infrastructure, not the company relay.
The vendor had quietly fallen back to “direct send” because the relay required TLS settings they hadn’t fully supported for that tenant.
SPF did exactly what it was supposed to do: flagged the mail as unauthorized. The assumption was wrong, not the mechanism.

Fix was boring and effective: either make the vendor use the relay for real, or authorize the vendor include in SPF and require DKIM signing
with the company domain. They chose the relay path to keep SPF small and stable. They also added a weekly DMARC report review.
The incident ended, and the lesson stuck: if you can’t point to the IP and the config, you don’t “know” the mail path.

2) Optimization that backfired: “Let’s flatten SPF for performance”

Another org had grown an SPF record like a junk drawer: six includes, two ip4 blocks, and a redirect for a subdomain.
They got spooked by the 10-lookup limit and decided to flatten everything—copy vendor IP ranges directly into the record.
This was pitched as “performance” and “resilience” because it removed dependencies on vendor DNS.

The flattening worked for a month. Then deliverability started wobbling. A marketing platform began using a new IP pool,
and because the org had frozen the old ranges into their SPF, those messages started failing SPF. Some receivers quarantined; some rejected.
The platform’s include record had been updated properly, but the org had opted out of that update stream.

The failure mode was subtle: internal testing still “passed” because engineers tested from one region and one sender.
In production, the vendor used different egress IPs based on geography and throughput. The flattened SPF record became a stale snapshot,
and the org had accidentally taken on the vendor’s IP lifecycle management.

They rolled back to includes for vendors that maintain them well, and used flattening only for sources they owned.
The bigger change was process: vendor onboarding now required either (a) a stable include record with published change practices, or (b) routing through the company relay.
Optimization is great—until it changes who is on the hook for keeping it correct.

3) Boring but correct practice that saved the day: staged strictness with DMARC reporting

A financial services firm ran a disciplined mail authentication program. Not exciting. Very effective.
They started with SPF ~all on a legacy domain because they genuinely didn’t know all senders. Instead of guessing, they instrumented.
DMARC was set to p=none with reporting enabled, and the security team reviewed aggregate reports weekly.

They found the usual surprises: a monitoring system sending “disk full” alerts directly from a colo IP, a regional office printer with SMTP auth,
and a small SaaS billing tool nobody had told central IT about. None of these were malicious. They were just unowned.
The reports made them visible, which is what good telemetry does: it turns mysteries into tickets.

After they aligned or replaced those senders, they switched SPF to -all and DMARC to p=quarantine.
Only then did they ratchet to p=reject for the primary domain, with subdomains handled separately.
When an attacker tried a basic spoofing campaign, most receivers rejected it cleanly. Internal teams barely noticed.

The “save” came later: a vendor outage forced a temporary reroute of outbound mail through a backup relay.
Because the firm had an explicit sender inventory and change process, updating SPF was a controlled change with a pre-lowered TTL and a rollback plan.
Their mail kept flowing. Nobody wrote a post about it on the internet, which is how you know it was done right.

Common mistakes: symptom → root cause → fix

1) Messages suddenly go to spam after switching ~all to -all

Symptom: Legitimate transactional mail starts landing in spam/quarantine at major providers.

Root cause: One or more legitimate senders were never authorized; softfail was being tolerated, fail is not.

Fix: Identify sending IPs from headers or logs, authorize via ip4/ip6 or include, or route through a known relay. Then re-test SPF and DMARC alignment.

2) Random receivers reject with “SPF permerror”

Symptom: Some recipients reject with 5.7.1 and mention permerror or “too many DNS lookups.”

Root cause: Your SPF record exceeds 10 DNS lookups due to includes/redirect/a/mx mechanisms.

Fix: Reduce lookups: remove unused includes, avoid a/mx unless necessary, consolidate senders, or use a relay. Re-check for duplication and syntax errors.

3) SPF passes but DMARC fails (and you can’t explain why)

Symptom: Authentication-Results shows spf=pass but dmarc=fail.

Root cause: SPF passed for an unaligned envelope domain (e.g., vendor bounce domain), and DKIM is missing or unaligned.

Fix: Ensure DKIM signing uses your From domain, or align the envelope sender domain; adjust DMARC alignment settings only if you understand the tradeoff.

4) Forwarded mail fails SPF and gets blocked after DMARC enforcement

Symptom: Employees forwarding mail to personal accounts (or partners) see rejections/quarantine.

Root cause: Forwarders break SPF; DMARC enforcement relies on DKIM passing and aligned, which may be missing.

Fix: Improve DKIM coverage for your outbound mail; consider ARC-aware receivers and list/forwarding best practices. Avoid relying on SPF for forwarded paths.

5) You published “v=spf1” as multiple TXT chunks and some systems misread it

Symptom: Intermittent SPF failures; different tools show different record strings.

Root cause: Record length/quoting issues or multiple records; some DNS UIs split strings poorly.

Fix: Ensure exactly one SPF TXT RRset and that it’s a valid SPF string. Validate with dig output and a local evaluator.

6) Vendor tells you to use “+all” or “?all” to avoid issues

Symptom: Vendor support suggests weakening SPF to “fix deliverability.”

Root cause: They can’t (or won’t) provide stable sending authorization and want you to accept everything.

Fix: Don’t. Route through your relay or demand DKIM signing with your domain and a proper SPF include strategy. If they can’t do that, reconsider the vendor.

Checklists / step-by-step plan

Step-by-step: safe path from ~all to -all

1. Inventory senders: list all systems that send as your domain (humans + apps + devices + vendors).
2. Enable DMARC reporting with p=none if you don’t already have it; assign an owner to read reports weekly.
3. Confirm DKIM coverage for every sender that can: marketing, ticketing, invoicing, HR, etc.
4. Fix alignment: ensure DKIM d= and/or SPF return-path align with From per your DMARC settings.
5. Clean SPF: one record only, no dead includes, avoid ptr, minimize a/mx.
6. Check lookup budget: keep plenty of headroom under 10. Don’t run at 9/10 and pretend it’s fine.
7. Lower TTL in advance (24–48 hours) before switching to -all so rollback is realistic.
8. Stage the change: apply -all first on less critical subdomains or a pilot domain if you can.
9. Monitor: watch bounces, receiver feedback, and DMARC reports for at least a full business cycle (week+).
10. Flip to -all and document the sender list as a living artifact tied to vendor onboarding/offboarding.

Operational checklist: before you touch SPF in DNS

• Do we know every legitimate sending path, including “small” tools (alerts, printers, legacy apps)?
• Do we have a rollback plan and a recent copy of the previous TXT record?
• Is TTL low enough that rollback matters?
• Have we verified there is exactly one SPF record today?
• Will this change push us toward the 10-lookup limit?
• Are we enforcing DMARC? If yes, is DKIM aligned for all major senders?
• Who is on point to handle deliverability tickets for the next 24–48 hours?

Decision rubric: what you should publish today

• Publish -all if: sender inventory is accurate, DKIM is broadly deployed, DMARC reports are reviewed, and you control or can constrain senders.
• Publish ~all if: you’re actively discovering senders with a time-boxed plan, and you can tolerate some spoofed mail scoring better than it should.
• Do not “solve” vendor problems with ?all or +all. That’s not a policy; it’s surrender.

Joke #2: Changing SPF without checking DMARC alignment is like tightening lug nuts on a car with three wheels. Technically you did work.

FAQ

1) Does -all guarantee receivers will reject unauthorized mail?

No. It signals “fail,” but the receiver decides what to do. Many will reject, some will quarantine, some will still deliver but score it harshly.
Your control is the accuracy and strictness of the signal, plus DMARC policy and DKIM.

2) Is ~all safer because it won’t break legitimate mail?

It’s safer only in the sense that some receivers are more forgiving. It also gives unauthorized senders a softer landing.
If you’re using ~all, treat it as a transition while you inventory and fix senders.

3) We use multiple vendors. Should we just add all their includes?

Sometimes. But includes are lookup multipliers and you have a hard limit. If you’re stacking vendors, you may be better off
routing outbound mail through a central relay you control, then authorizing just that relay in SPF.

4) Why does forwarding break SPF?

SPF checks the connecting IP against the envelope sender domain’s SPF record. A forwarder changes the connecting IP but usually keeps the original envelope sender.
Result: unauthorized IP, SPF fails. DKIM can survive forwarding and rescue DMARC alignment if it’s correctly configured.

5) Should I use include or list IP ranges directly?

Use include when the vendor maintains it well and changes IPs. List IPs directly when you own and control them.
Flattening vendor ranges into your SPF makes you responsible for tracking their IP churn, which is a job you probably didn’t budget for.

6) What’s worse: temperror or permerror?

In practice, permerror is worse because it’s persistent and signals broken configuration (syntax, multiple records, lookup limit).
Temperror can be intermittent (DNS outages), but at scale it still hurts deliverability. Either one is a reason to simplify and harden DNS.

7) Can I use SPF to stop someone spoofing my From: address?

Not reliably. SPF authenticates the envelope sender domain. Attackers can pick an envelope domain they control while spoofing your visible From:.
DMARC is what ties authentication to the From: domain (alignment). Use SPF as part of the stack, not the whole stack.

8) We have DMARC set to reject. Does that mean SPF must be -all?

Not strictly. DMARC can pass via DKIM even if SPF fails. But if DKIM coverage is incomplete, SPF strictness suddenly matters a lot more.
If you’re enforcing DMARC, you should be confident in DKIM first, then make SPF strict and accurate.

9) What about subdomains—should they inherit the apex SPF record?

Only if the sender set is truly identical. Marketing platforms and product systems often use subdomains for a reason. If you redirect everything to the apex,
you can accidentally authorize senders for places they shouldn’t be, or break legitimate subdomain senders.

10) How do I know if switching to -all will backfire?

If you can’t answer “what are all legitimate sending IPs/domains?” and “do they DKIM-sign aligned?” with evidence (logs, headers, DMARC reports),
you’re not ready. Use ~all temporarily, instrument, fix, then move to -all with a staged rollout.

Conclusion: what to do next

If you want the setting that won’t backfire, don’t treat ~all vs -all as a moral debate. Treat it as readiness.
Softfail is a probation period. Fail is production.

Practical next steps:

1. Run the DNS checks above and confirm you have exactly one SPF record and a sane TTL.
2. Pull headers from real mail and write down the actual connecting IPs for each sender system.
3. Fix DKIM and DMARC alignment for your major senders, especially anything that gets forwarded.
4. Reduce SPF lookup complexity before it turns into permerror roulette.
5. Move to -all with a staged change, monitored for at least a week of real traffic.

The goal isn’t to publish a scary-looking record. The goal is to publish a record you can defend at 2 a.m. with logs, headers, and a rollback plan.
That’s how you keep email authentication from becoming an accidental denial-of-service against your own business.