domain name system - Does "~all" in the middle of an SPF record signal the end of the record when it is parsed?

Our company's SPF record format is as follows:

"v=spf1 include:_spf.google.com ~all a mx ip4:X.X.0.0/23 include:spf.example.com ?all"

So we have an "~all" in the middle of our SPF record. On the openspf.com website, they say this regarding the "all" mechanism:

This mechanism always matches. It usually goes at the end of the SPF
record.

So, they don't say "all" HAS to go at the end of the SPF record, but that it USUALLY goes at the end.

At our company, lately we've been seeing some soft fails in emails sent from servers listed in our SPF record, yet our SPF record passes all validation tools I've found so far.

What I'm wondering is, would this "~all" directly after the include for Google Apps (_spf.google.com) cause parsing to stop and not recognize the remaining pieces of the SPF record? Would passing vs. soft-failing depend on who is parsing it and their specific implementation of how they process SPF records? Is there any reason to have an "all" mechanism that is not at the end of an SPF record?

And yes, I know we could just change our SPF record. This question is more about clarifying how this all works and not necessarily about resolving our specific situation.

Answer

RFC 7208 § 5.1 is explicit about this: after all appears, everything after it MUST be ignored.

Mechanisms after "all" will never be tested. Mechanisms listed after "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be ignored when there is an "all" mechanism in the record, regardless of the relative ordering of the terms.

The RFC it obsoleted, RFC 4408, said much the same thing; the newer version of the RFC simply clarifies the intention.

Mechanisms after "all" will never be tested. Any "redirect" modifier (Section 6.1) has no effect when there is an "all" mechanism.

So, conforming implementations of SPF will completely ignore everything after the first ~all. This doesn't mean, however, that every implementation conforms to the spec. In particular, this was probably thought worthy of clarification precisely because one or more implementations did not conform.

It's not at all clear why an online validation tool would not catch this misconfiguration, but if you intend for anything after the first all to be used, you should correct the record, as proper implementations will ignore it.