Why so many IP addresses?

Capacity

One reason is “to be able to send a lot of email”. Any sane network setup is going to need at least one external IP address for each mailserver. A low end mailserver can send a few tens of thousands of emails an hour, in the best case, while a mid-range commercial email cannon can send ~100k an hour, and a high end (expensive) one maybe 10x that. At least in perfect conditions. In the real world, where recipients mailservers are overloaded, have long timeouts, defer connections and are just generally slow the number of SMTP connections you need to keep open simultaneously to get that sort of delivery rate goes up spectacularly – and that tends to be a limiting factor.
So, realistically, if a client wants to be able to send a message to most of their 100k recipients in a half hour window, they might to need to send from several addresses.
One mail engineer I talked to mentioned a customer with half a million recipients who was concerned about getting mail out to their recipients in a tight window. Switching from one source IP to two ended up delivering the same mail to the same recipients a third faster.

Reputation

While modern spam filtering is sophisticated, and relies heavily on domain-keyed reputation and message content, the first level of filtering is IP-keyed.
Mail from an IP address that’s consistently sent reasonable quantities of messages that have been generally liked by the recipients is going to be able to deliver mail faster and more reliably than an IP address that doesn’t have a recent history of sending mail, or which has a history of sending unwanted or mediocre mail.
Put simply, consistently “good” senders get decent delivery, while “bad” or “mediocre” or “inconsistent” senders tend not to. Even if a sender sends wanted email, if they’re not sending it fairly regularly recipient ISPs will likely forget about their good behaviour and they’ll have problems when they try a large delivery after a long pause.
So there are two things that are needed to keep delivery healthy from an IP address. Mail needs to be sent at fairly consistent volumes, fairly regularly and it needs to be consistenly good email.
This leads to shared IPs (and shared pools) vs dedicated IPs.
If you have multiple customers sending from the same IP address then the reputation of those customers will be shared. Poor customers will be rewarded by better delivery rates than they’d get sending on their own, while good customers will be punished by having the quality of their delivery dragged down by the poor senders on the same address. That’s the opposite of what you want to happen if you’re encouraging customers to focus on behaving well.
But if you put customers who send very little email on their own dedicated IP addresses then they won’t send enough mail for that IP address to build or maintain a reputation with recipient ISPs. For those customers, sharing an IP address with others – of similar quality – will bring up the total volume sent from that address to a level that will benefit delivery.
So from the perspective of an ESP who wants to encourage customers to focus on what they’re doing and to behave well in all aspects of their email campaigns the ideal is to have any customer who is sending enough email to justify it on their own dedicated IP addresses, while having enough shared IP addresses to put smaller customers on. The larger customers’ delivery success will be driven primarily by their behaviour.
In the case of customers who send several decidedly different mail streams (transactional vs marketing, say) you may want to segregate those out to different IP addresses too, so that their marketing and ops groups have separate incentives to keep their marketing and transactional campaigns, respectively, clean.
So a couple of dedicated IP addresses per medium-to-large customer isn’t unreasonable operationally. More, if they send a lot of mail.
Customers also like dedicated IPs for several tangential reasons. They can use their own domain in reverse DNS and hostnames, which doesn’t have much operational effect but they like. It’s much easier to get data from feedback loops from a dedicated IP address, and third party reputation monitoring is more meaningful.

Redundancy

Stuff breaks. Mailservers crash, network connections go down, DNS infrastructure falls over, datacenters catch fire, backbone providers have contract disputes. And, sometimes, mail from an IP address will end up being undeliverable to a particular destination for no good reason.
So if your mail is valuable, you want a backup plan.
With most services you can engineer your system to be fairly robust against outages – keep backend data replicated between redundant sites, spin up new front end servers as needed or keep them idle at the backup site until you need them.
Because of the whole IP reputation thing, that’s nowhere near as simple to do if you’re sending email.
You could justify having a second set of IP addresses for each customer, duplicating their primary set. And, in order to keep those addresses “warm” you might want to spread deliveries across both sets normally, and still have the capacity to send their normal level of mail on just a single set if something breaks (or if you need to take something down for maintenance, or …).
I’ve very rarely seen this level of redundancy used in the wild, at least not by reputable ESPs. If a router goes down for six hours and it delays a customers send … that’s annoying, rather than mission critical.
I have seen less reputable ESPs (avoiding the “S” word here, but you know what sort of sender I mean) who’ll move a customer from IP address to IP address when they get blocked. That’s not what I mean by redundancy.

Policy

So, that’s all technical justifications for assigning IP addresses based on customers. What does a more real world policy look like?
I asked a couple of policy people at ESPs – ESPs I consider to be pretty smart, both in technical and business / policy ways – what they did.

“They get one.”

I like this policy. It’s simple to explain and to justify. Any customer that can benefit from a dedicated IP address gets a single IP address. This ESP doesn’t tend to have customers who send so much mail that they’ll overwhelm the capacity of a single IP address, so there’s no need to look at higher volumes than that.

“At 100k-200k/mo they get one. At 2M+/day they get one per 2M/day. If they’re segmenting marketing mail from transactional they can get additional ones as needed.”

Again, easy enough to explain and to justify. Customers who are too small to benefit from a dedicated IP address don’t get one. Once you get significantly over 2M/day delivery metrics start to get worse, deferrals tend to happen more… so 2M/day/IP is operationally justified.
What’s the downside, from a policy perspective? Until you actually run out of IPv4 addresses it’s easy for sales reps to keep giving them out to new customers. Customers that could send perfectly successfully from shared addresses – especially pooled addresses that were stratified by customer reputation and volume – still want a dedicated IP address when they’re talking to sales. And you can’t move a customer from a dedicated IP address to a shared pool without loud objections.
So the number of IP addresses an ESP is using hardly ever decreases, rather it keeps ratcheting up until you’re using many more than you actually need.
On the one hand using them profligately rather than facing the policy and engineering challenges now is going to make hitting the wall of “we can’t get any more IPv4 addresses” more painful. On the other hand it does mean you’ll have a hoard of them to reallocate to soften the blow when it does happen.
I’ll talk about the “how did the ESP get all these IPv4 addresses anyway?” aspect on Monday.