Most SPF problems are not typos. They are a record that grew past a limit nobody was watching.
Evaluation is capped at ten DNS-querying terms. Cross that line and receivers return PermError, which does not mean slightly degraded — it means the check failed, and a DMARC policy sitting on top of it loses the SPF half of its evidence. Nothing in your DNS control panel warns you, and mail keeps flowing until a receiver decides to act on the failure.
The trap is that the budget is spent recursively. Your record might contain three includes, but each resolves to a record that spends lookups of its own. Add a marketing platform, a helpdesk, and a payment processor, and a record that reads as short can genuinely cost fifteen lookups.
Getting back under the limit
In rough order of how much I would recommend them: remove includes for services you no longer send through, which is usually where the easy wins are; replace an include with the specific ip4 ranges it resolves to, accepting that you must now track the provider's changes yourself; and consolidate senders so fewer platforms send as your domain at all.
Flattening tools exist and they trade a lookup problem for a maintenance problem — the ranges go stale silently, and the day a provider changes IPs your legitimate mail starts failing. Prefer removing includes over inlining them.
SPF is one leg of three. Check your signing keys with the DKIM checker, and confirm which hosts accept mail for the domain with the MX lookup.