To help celebrate Deliverability Week 2024, Al Iverson from Spam Resource has offered up a guest post! Take it away, Al!

Here’s a common question we get asked in email deliverability land: How do we perform IP warming for transactional email messages? Is it even necessary?

Before I answer that, let me backup a minute and remind readers what IP warming actually is.

Mailbox providers – especially the big ones that handle all the mail for consumer email inboxes – think Gmail, Yahoo, Microsoft, etc., are suspicious of attempts to send emails to them from servers, from IP addresses and domains, that haven’t sent them email messages previously. Indeed, one time years ago, a representative from Microsoft explained to me that, basically, 98% of new email server connections are from bad guys trying to spew some sort of garbage – meaning, when an email server connects to one of their inbound email servers at Microsoft – almost every time, it’s somebody trying to offload spam, malware, phishing or spoofing.

This leads to a “guilty until proven innocent” scenario where when you’re a new email marketing sender, often on a new dedicated IP address or dedicated mail server (or even sometimes when on a shared mail server or shared IP address), it can be very difficult to get enough mail delivered to get to the point where these big mailbox providers will come to understand that you’re a good entity trying to send wanted and engaging email messages.

Thus, the concept of IP warming was born. The concept is relatively simple: Start out at very low volumes of email per day. Send only a tiny bit more each day or week. Eventually you’ve gotten to a point where, by gradually increasing the volume of mail sent per day, you’re now free to send as much marketing mail as you like. (As long as it’s wanted mail and configured correctly, of course. A completed IP warming process does not exempt a sender from best practice requirements and spam limits.)

The exact volumes-per-day for IP warming can vary; ask ten different deliverability consultants and you might get a dozen different answers. Here you can find the common IP warming guidance I used to provide to clients of Salesforce Marketing Cloud. My typical guidance for a new marketing sender on a new dedicated IP address nowadays would match this: for the first three days, send no more than 500 messages per day, and slowly grow from there.

Limiting email volume this way is often easy to do for a large email marketing sender. If they’ve got a list of a million subscribers that they wish to send a weekly advertising email to, they can easily map this process out to build up to the point where they can launch their weekly email to the whole audience of one million, without much trouble (usually).

But what about transactional email messages? What’s different, and what’s the same, when it comes to IP warming?

First, know that for any new mail stream, especially on a new dedicated IP address that hasn’t sent any mail previously, IP warming is required. That means that if you’re adding a new sending IP address for transactional messages, you’ve got to go through that IP warming process, just like if it was going to be for sending marketing messages.

But, limiting transactional volume is tricky. You don’t really want to prevent email recipients from receiving important, expected transactional communication. Order receipts, shipping notifications, password resets. Not receiving these when expected can and will make people unhappy.

So, while you do have to engage in IP warming, you’ll have to do it in a way that helps eliminate the chances of a recipient not receiving that important transactional email communication.

Once, for an online pet-related retailer, transitioning from a homegrown system to a large ESP platform, I helped a customer work through this very scenario. We mapped out the different types of transactional messages that they were sending: Order receipts, shipping status, renewal/re-order status, refund/cancellation details, password reset emails, and support ticket responses. We had information about typical daily, weekly and monthly volume for each type of send. What we ended up doing ended up being relatively simple – each week, we moved one type of communication from the old platform to the new platform. We started with the least common type of transactional email, which kept us under that 500 messages limit. And volume grew as we added in the more common types of messages, but we introduced each type one at a time and waited a bit to make sure we were seeing good deliverability results before adding in more and more transactional messaging over on the new ESP platform.

After about 6-7 weeks of transitioning, we were done. All transactional messages were now sending to the world from the new ESP platform, and we had zero deliverability glitches along the way.

Maybe you won’t get lucky to have different types of messaging that you can split up. But maybe your client has a web developer that can modify the feed from their commerce platform to email gateway to limit email volume that way. A simple counter to send only every 3rd or 7th message to the new ESP platform, or to limit messages to X per day while growing that limit day-by-day, that will help you implement IP warming successfully while not preventing messages from being sent.