Return Path: When is it OK to Use a Shared IP Address?
URL Copied
Return Path's Tom Sather explains when it's OK to use a shared IP address. Basically, when your volume is very low. He suggests that the cutoff be 50,000 messages a month -- below that level, you should be on a shared IP address. Above that, a dedicated IP address is recommended. I personally think there's some flexibility there, but overall, you do have to draw a line somewhere, and it's pretty good guidance. (I usually recommend that senders mailing to more than 100,000 recipients per month utilize a dedicated IP address.)
The one obvious question that I think goes along with this is, when is it NOT okay to use a shared IP address or shared IP address pool? Here are three scenarios where I think it is truly NOT okay to use a shared IP address or shared IP address pool. When you think you have to use a shared IP address to prevent reputation-related blocking. If that's truly the case, you have a deliverability issue you have to fix. Your mail stream is the issue; not what IP address you are using. You can't hide your mail behind other senders' mail forever -- it will catch up with you. What you're doing is slowly dragging down the reputation of the shared IP address. This will lead to problems for the other (good) senders on that IP address, who will be negatively impacted through no fault of their own. Would you want to be that other customer in this scenario? It might be good to know who your neighbors are, and make sure your ESP works to ejects the bad ones out of the neighborhood. When you have to send millions of messages on day one just after changing ESPs or platforms. Shared IP addresses or shared IP pools don't really have the capacity for this. A single IP address can support sending approximately between one to two million messages per day. Modern MTA hardware allows much faster sending than that, but realistically, top B2C ISPs will rate limit you if you try to send beyond these limits. It's too much, too fast, from their perspective. You also are vastly increasing the volume of mail being sent over a shared IP address. That IP address probably wasn't sending to three million people yesterday -- and now you've added that additional volume. Volume bursts like this are another thing that cause ISPs to throttle, slow down, or block mail from senders. What you're doing here is taking a shortcut path that is problematic; doesn't execute very well, then leaves a reputation problem behind for somebody else to have to clean up.
When you send millions of messages every month. This is implied in Tom's guidance, but let's expand upon the thought. You're sending thousands to millions of messages per month. Subscribers recognize you and your mail is expected and wanted. You're going to have solid deliverability stats and solid inbox placement. Why muck things up my mixing up your mail streams with the mail streams of other senders? Don't let somebody else's send, something out of your control, cause a block at Comcast because they sent to too many invalid users. Stuff like this happens every day, and not just at Comcast. Spamhaus sees the spamtrap hits coming from a given sending IP address, so they'll pick out the bad guy. But they don't usually see the good mail also coming from that IP address, because it's not being sent to spamtrap addresses. If they think the IP address is sending too much mail to spamtraps, they could end up blacklisting it, and then you're blocked at a whole bunch of ISPs, again because of something some other sender did -- not because of anything you did.
Using a shared IP address is a necessity for smaller volume senders. But using a shared IP address makes it harder for ISPs to calculate your sending reputation. Makes it harder for your good reputation to shine. Makes it impossible for you to get Return Path Certified. That's why, if you have enough volume, let your good reputation shine through by using a dedicated sending IP address. June 11, 2015 Update: Don't just take my word for it: Here's what Return Path's Jennifer Cheng says about when not to use a shared IP address.
Return Path's Tom Sather explains when it's OK to use a shared IP address. Basically, when your volume is very low. He suggests that the cutoff be 50,000 messages a month -- below that level, you should be on a shared IP address. Above that, a dedicated IP address is recommended. I personally think there's some flexibility there, but overall, you do have to draw a line somewhere, and it's pretty good guidance. (I usually recommend that senders mailing to more than 100,000 recipients per month utilize a dedicated IP address.)
The one obvious question that I think goes along with this is, when is it NOT okay to use a shared IP address or shared IP address pool? Here are three scenarios where I think it is truly NOT okay to use a shared IP address or shared IP address pool.
When you think you have to use a shared IP address to prevent reputation-related blocking. If that's truly the case, you have a deliverability issue you have to fix. Your mail stream is the issue; not what IP address you are using. You can't hide your mail behind other senders' mail forever -- it will catch up with you. What you're doing is slowly dragging down the reputation of the shared IP address. This will lead to problems for the other (good) senders on that IP address, who will be negatively impacted through no fault of their own. Would you want to be that other customer in this scenario? It might be good to know who your neighbors are, and make sure your ESP works to ejects the bad ones out of the neighborhood.
When you have to send millions of messages on day one just after changing ESPs or platforms. Shared IP addresses or shared IP pools don't really have the capacity for this. A single IP address can support sending approximately between one to two million messages per day. Modern MTA hardware allows much faster sending than that, but realistically, top B2C ISPs will rate limit you if you try to send beyond these limits. It's too much, too fast, from their perspective. You also are vastly increasing the volume of mail being sent over a shared IP address. That IP address probably wasn't sending to three million people yesterday -- and now you've added that additional volume. Volume bursts like this are another thing that cause ISPs to throttle, slow down, or block mail from senders. What you're doing here is taking a shortcut path that is problematic; doesn't execute very well, then leaves a reputation problem behind for somebody else to have to clean up.
When you send millions of messages every month. This is implied in Tom's guidance, but let's expand upon the thought. You're sending thousands to millions of messages per month. Subscribers recognize you and your mail is expected and wanted. You're going to have solid deliverability stats and solid inbox placement. Why muck things up my mixing up your mail streams with the mail streams of other senders? Don't let somebody else's send, something out of your control, cause a block at Comcast because they sent to too many invalid users. Stuff like this happens every day, and not just at Comcast. Spamhaus sees the spamtrap hits coming from a given sending IP address, so they'll pick out the bad guy. But they don't usually see the good mail also coming from that IP address, because it's not being sent to spamtrap addresses. If they think the IP address is sending too much mail to spamtraps, they could end up blacklisting it, and then you're blocked at a whole bunch of ISPs, again because of something some other sender did -- not because of anything you did.
Using a shared IP address is a necessity for smaller volume senders. But using a shared IP address makes it harder for ISPs to calculate your sending reputation. Makes it harder for your good reputation to shine. Makes it impossible for you to get Return Path Certified. That's why, if you have enough volume, let your good reputation shine through by using a dedicated sending IP address.
June 11, 2015 Update: Don't just take my word for it: Here's what Return Path's Jennifer Cheng says about when not to use a shared IP address.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.