This is typically handled by creating multiple TXT records. You can see _spf.google.com do it.
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
In your case you would create new TXT records similar to...
spf1.example.com 300 IN TXT "v=spf1 include:mail.zendesk.com include:stspg-customer.com include:_spf.google.com ~all"
spf2.example.com 300 IN TXT "v=spf1 include:et._spf.pardot.com include:sendgrid.net include:spf.mandrillapp.com include:mailsenders.netsuite.com ~all"
And set your SPF record to something like...
"v=spf1 ip4:206.190.89.129/27 ip4:54.86.80.254/32 ip4:13.111.0.56/32 include:spf1.example.com include:spf2.example.com ~all"
The danger to records this large is that the SPF RFC 7208 says in section 4.6.4 that only 10 modifiers that require DNS lookups will be honored by systems doing SPF checks. The google SPF record I quoted includes huge lists of netblocks specifically to avoid hitting this limit, and the rest of your includes all point to netblocks. The SPF record you quoted is at 7 all by itself, and the google include adds 3 more (they have a lot of netblocks).
You're at 10 already. Unfortunately, using the method I mention here will add two more and put you into the zone where mail receivers may not fully query all of your authorized netblocks. You're fast approaching the area where SPF stops being a viable method of control and you'll need to do something like dmarc in order to get the non-repudiation you need. In that case you'd use an SPF record with "v=spf1 +all" which tells mailers that you don't actually care who sends your email and you're using something else. When paired with dkim and DMARC, you get the nonrepudation features you're looking for.
