What exactly IS the problem here?
Your volume is not high enough to justify splitting - I mean, even if all your 30 customer s send out 20.000 emails at once, that is not THAT much - enough for ONE powerfull server to handle (and I don't mean super powerfull - just get some discs and form a raid for the mail spool).
You could possibly go with multiple sending servers for queueing. A block of IP addresses for all mail servers. Either using somehting like MS Exchange for sending (exchange is great in automatically maintaining server farms), or using some mechanism to cluster emails between servers (so that those to the same domain end up on the same server - simply because the server can then send multiple emails in one TCP connect).
Multiple ISP's sounds like a non-issue. Do not forget - we talk about way too much traffic for a cheap home ADSL line. Once you get business grade, your servers move into a proper data center. Uptime is very high then - for a proper one (carefull, some really seem cheap). Even if thigns go down a day in 2-3 years, you have to be REALLY big or clustering to make sense. And even then things can go really bad (as in: Wikipedia also was down for some time recently).
The main issue willb e you need dedicated servers built on specs to handle the mail flow. Network traffic is not that much. But the mail spool will be reall hard on your discs. If you really get spikes of 600.000 emails, a RAID 10 of 4-8 high speed discs (or: A raid 5 of SSD's) sounds like the best bet. Like all database transactional systems your limit will be the IO. I would go with a custom formatted file system with non-standard node size (64k), allowing every email to be read/written in on node pretty much per guarantee. Note that this is based on SPIKE usage - if the emails dont get all send at once, you can get away with a lot less.
Next step would be a cluster of servers.