Does this cause an SPF syntax error?

No, and that is the problem. The record is syntactically valid. Terms after all are simply unreachable, so the failure is silent and shows up only as mail that unexpectedly fails SPF.

Do modifiers like redirect and exp have to come before all as well?

Modifiers are position independent, so redirect and exp are read wherever they appear. But redirect is only consulted when no mechanism matches, and all always matches, so a record containing both all and redirect will never use the redirect.

Why did my new sender stop failing after I moved one word?

Because moving all to the end made the mechanisms before it reachable. Evaluation stops at the first match, so a mechanism placed after all is never consulted regardless of how it is written.

MediumAuthentication

SPF record has mechanisms after the all term

There are terms after the all mechanism in this record. Because all matches every sender, evaluation always stops there: anything written after it is unreachable and silently ignored. The record is valid, which is what makes this dangerous: a sender you believe you authorised is not authorised, and nothing reports an error.

Check your own domainSPF checker

What causes this

SPF is evaluated left to right and the all mechanism always matches. Anything after it is dead configuration: a receiver reaches all, returns its result, and never looks further. This usually happens when a new include is appended to the end of an existing record instead of being inserted before the all term.

What it breaks

The sending services listed after all are not authorised, even though the record appears to include them. Their mail fails SPF.

What the receiving server does

SPF is evaluated strictly left to right, and the first mechanism that matches determines the result. The all mechanism matches unconditionally, so it is the last thing ever evaluated. A receiver reaching it returns the qualifier attached to it and stops. It does not warn, and it does not report a syntax problem, because there is not one: the record parses correctly and behaves exactly as specified. The only observable symptom is that mail from the sender listed after all fails SPF for no apparent reason.

The include that never runs

This normally happens when a new sender is appended to the end of an existing record rather than inserted before the closing all. The edit looks right, the record stays valid, and the new sender is never authorised.

1v=spf1 include:_spf.google.comevaluated: Google is authorised

2~allmatches everything, and evaluation stops here

3include:sendgrid.netnever reached: SendGrid is not authorised

fixv=spf1 include:_spf.google.com include:sendgrid.net ~allall belongs last, always

How to fix it

Move every mechanism to before the all term.

Take the mechanisms currently sitting after all.
Reinsert them before the all term, keeping their order.
Ensure all is the final term in the record.

If you send with

Adding a new sending service: When a provider tells you to append their include to your SPF record, append means before the trailing all, not after it. This is the single most common way the mistake is introduced, because the instruction is usually written as though your record has nothing at the end.

Confirming the fix worked

Move every mechanism to sit before the all term, and confirm all is the final term in the record.
Confirm there is only one all term. A record with two has the same problem in a less obvious form.
Re-run the check above and confirm the sender you were trying to add now appears as authorised.
Check the lookup count after the move, since a mechanism that was previously unreachable now costs lookups it was not costing before.

Common questions

Does this cause an SPF syntax error?: No, and that is the problem. The record is syntactically valid. Terms after all are simply unreachable, so the failure is silent and shows up only as mail that unexpectedly fails SPF.
Do modifiers like redirect and exp have to come before all as well?: Modifiers are position independent, so redirect and exp are read wherever they appear. But redirect is only consulted when no mechanism matches, and all always matches, so a record containing both all and redirect will never use the redirect.
Why did my new sender stop failing after I moved one word?: Because moving all to the end made the mechanisms before it reachable. Evaluation stops at the first match, so a mechanism placed after all is never consulted regardless of how it is written.