Dear Laura,
Your blog is the best. Nothing else compares for solid deliverability discussion.
I’ve frequently read these two articles:
I need IP addresses to avoid throttling
I need to deliver my mail fast
They are incredibly helpful.
But I don’t think you’ve ever answered this question directly:
“Is it detrimental to use an IP pool instead of a single, static IP? For example, if senders each have a list of 100,000, they will see slow delivery times and large queues at certain ISPs like Outlook if they use a single sending IP, even if the sending is very high quality. Will it hurt them to use an IP pool to try and achieve faster delivery? Are static IPs preferable to an IP pool?”
This is a loaded question, but I haven’t found a satisfactory answer so far.
it seems like it was easier to deliver messages in 2009 and deferrals were not as strict, leading to less queue time in the MTA. Now, it’s more common to see deferrals and big delays.
Basically, it seems justifiable to use an IP pool (multiple IPs in a VMTA) if you have a large volume (millions of messages) of mail being sent from that VMTA because this helps the messages deliver faster, especially at Outlook where they have more conservative rate limits. But does this come at a cost? Is it “suspicious” to be sending with multiple IPs at once, even if they all have a good reputation?
Sincerely,
Leaping into the Pool
Dear Pool,
You’re right, it’s not a question I’ve answered publicly before. Some of that is because, as with so much in deliverability, the details matter. Sometimes the answer is yes, sometimes the answer is no. Thanks for the level of detail here, making it easier to answer the question.
Dedicated pools are usually fine to use in certain circumstances. The rule of thumb I use is that an IP is good for about a million emails a day. Companies that are consistently sending more than that may want to consider adding more IP addresses to handle the volume.
When sending from a pool of IPs, rather than a single IP, there are a few things to remember.
- Your pool of IPs should be as close to each other as is possible on network terms. It’s not always possible to get your ESP to give you adjacent IPs to use for the pool, but ask them for IPs as close to each other as possible. You should never spread a pool across different networks or different providers.
- Any new IPs will need to be warmed up. This may offer you the opportunity to move to a pool of connected IPs, giving up the old IP. Or you can use the older IP for other types of mail and move all your bulk mail to the new IP range.
- You should continue to sign with the same DKIM d= domain on the new IPs. This may help speed up the process of warming up the IPs. Using the same naming convention for rDNS is also a good idea. Do not decide that moving IPs is the right time to change d= domains. It almost never is.
- Expect the IPs in the pool to sometimes have different reputations. Why? It’s unclear why this happens, but I’ve seen enough data from colleagues and clients over the years to say it does. Just because the IPs are sending the same mail to the same recipients doesn’t mean that the reputations are the same. Some of it is likely due to statistical variance, but that’s as much hand waving and speculation as I am going to do.
The biggest caveat about doing this is a pool of IPs will not help if the delivery delays are the result of poor reputation. If your mail has a bad reputation sending it through more IPs is only going to mean you have delayed mail across those IPs. Also, sending identical emails across too many IPs for the volume you’re sending, particularly if those IPs are on separate networks, is a good way to run into some of the anti-snowshoeing filters. CSS is the most public snowshoe filter, but don’t let that lull you into complacent. Every ISP has their own internal measurements of how many IPs are sending the same mail and cross whatever their threshold is with low quality mail and you could see blocks or bulk foldering.
These are the types of questions your ESP’s delivery team can usually help you with. If you don’t have an ESP or their team isn’t being helpful, these are the types of questions we help clients address as part of our strategic consulting.
Confused about delivery in general? Trying to keep up on changing policies and terminology? Need some Email 101 basics? This is the place to ask. We can’t answer specific questions about your server configuration or look at your message structure for the column (please get in touch if you’d like our help with more technical or forensic investigations!), but we’d love to answer your questions about how email works, trends in the industry, or the joys and challenges of cohabiting with felines.
RSS - Posts