Shared-IP warm-up advice often gets reduced to, "you cannot warm anything because the ESP owns the IPs."
That is the wrong conclusion.
If the ESP controls the sending IPs, IP warm-up is mostly their job. But domain and stream warm-up are still your job. Mailbox providers still have to decide whether your From domain, your DKIM domain, your audience quality, and your traffic pattern look trustworthy.
So the practical question is not "can a domain warm up on shared IPs?"
The practical question is: how do you introduce a new or expanded sender identity safely when the infrastructure reputation is partly shared with other customers?
Yes, you should still ramp volume on shared ESP infrastructure.
What you are ramping is usually not a raw IP reputation reset. You are ramping:
From domain or subdomainGoogle is explicit that Gmail tracks volume, feedback, and limits per domain and IP address, and that the IP quota on a shared IP is shared across all senders on that IP. Google also recommends gradual increases, consistent rates, and separate ramping after significant infrastructure or header changes. Source: Google's Email sender guidelines.
That single paragraph explains most of the operational reality on shared infrastructure.
You do not control the whole IP pool, but receivers still observe your domain's behavior on top of it.
On a dedicated IP, warm-up is easy to visualize: a cold IP starts sending more mail over time.
On a shared ESP, the IP pool may already be warm in the sense that mailbox providers have history for those IPs. What is still new is often your exact sender profile:
From domaind= domainThat is why a team can move to a reputable shared ESP and still get throttled or junked when they blast a new promotional stream on day one.
The pool is not necessarily the problem. The new behavior on the pool is.
Google's sending-practices guidance says DKIM and SPF quotas are specific to your domain, while the IP quota is shared for all senders using that IP. Source: Google's Email sender guidelines.
That matters because it means Gmail is not looking only at the shared pool. It is also tracking how your authenticated domain behaves.
Microsoft makes the same broader point from a different angle. Its documentation says mail evaluation uses not only SPF, DKIM, and DMARC, but also sender reputation, sender history, recipient history, and behavioral analysis. Source: Microsoft Learn's Email authentication.
So even if your ESP has healthy pool management, receivers can still decide that your stream is risky if they see:
Shared infrastructure changes a few things:
What it does not change:
Google and Outlook.com now both apply sender requirements to high-volume domains, not just infrastructure. Google permanently classifies bulk senders by primary domain once they cross the threshold, and Outlook.com's 2025 high-volume sender announcement requires SPF, DKIM, and DMARC for domains sending more than 5,000 messages per day. Sources: Google's Email sender guidelines FAQ and Microsoft's high-volume sender announcement.
Treat it as a warm-up case when one or more of these are true:
From domain is new to the audiencenews.example.comThe fact that the ESP's pool is established does not cancel these risks.
Sometimes the real issue is not your ramp discipline.
If a well-behaved, low-complaint stream with stable volume suddenly shows broad delivery problems across providers, the shared pool itself may be under stress. Google tells senders using shared IPs to monitor the shared IP reputation in Postmaster Tools when possible. Source: Google's Email sender guidelines.
That is the point where you press the ESP for specifics:
Shared-IP sending means some deliverability variables are outside your direct control. That is true. It is just not the only truth.
The safest plan is deliberately boring.
Make sure the exact stream you are ramping has:
From naming and reply handlingFor direct mail to Gmail as a bulk sender, the From domain must align with either SPF or DKIM. Source: Google's Email sender guidelines.
If you are still sorting out alignment basics, DMARC and sender domain warm-up is the best companion read.
Google recommends starting with engaged users first and increasing volume slowly over time. Source: Google's Email sender guidelines.
On shared infrastructure this matters even more, because you want early feedback to show that your stream belongs in the inbox. That means:
The early stage is not where to prove list size. It is where to prove recipient intent.
Do not mix receipts, alerts, newsletters, and promotions in one warm-up motion.
Google explicitly recommends different IP addresses for different message types when possible and warns against mixing content categories in the same message. On shared infrastructure you may not control the IP split, but you do control whether your stream is operationally consistent. Source: Google's Email sender guidelines.
If the ramp is for promotional mail, keep it promotional. If it is for product notices, keep it narrowly product-notice shaped.
Do not decide in advance that day 3 must be double day 2.
Increase only when the previous segment looks healthy enough:
Google's guidance is clear here too: if bounces or deferrals increase, reduce the sending volume until the SMTP error rate drops, then increase slowly again. Source: Google's Email sender guidelines.
This is the shared-IP mistake that causes most bad postmortems.
Teams often do all of this together:
Then the failure gets blamed on "shared IPs."
Usually the safer rule is: change one major trust signal at a time whenever feasible.
Google specifically says that after significant infrastructure or email header changes, the modified segment of traffic should be increased separately. Source: Google's Email sender guidelines.
There is no universal number because safe starting volume depends on:
That is why mailbox-provider guidance tends to say start low and increase gradually instead of publishing one fixed table.
As a rule of thumb, the less established the stream is, the more you should think in small engaged cohorts rather than campaign-wide sends.
For a new promotional stream on a shared ESP, the risk usually comes from a bad first impression, not from failing to hit a textbook day-by-day quota.
Ask these questions in order:
If authentication is clean, the audience is strong, and problems are broad and sudden, the shared pool may be the main issue.
If authentication is clean but only the new stream struggles after a large jump to mixed-quality recipients, the domain or stream rollout is the more likely issue.
DMARC does not replace warm-up. It gives receivers a stable aligned identity to score.
That is especially important on shared infrastructure because the IP layer is not exclusively yours. If the IP can vary inside the ESP's system, the aligned sender identity becomes even more important as the stable trust anchor.
Google requires alignment for direct bulk mail, and Microsoft's high-volume sender requirements also center SPF, DKIM, and DMARC at the domain level. Sources: Google's Email sender guidelines and Microsoft's high-volume sender announcement.
If your ESP signs with your domain and your visible From domain is stable, that gives mailbox providers a much better basis for building positive history than a loosely aligned setup.
When you do not control the sending IPs, warm-up does not disappear. It just shifts focus.
You are usually warming up the domain, subdomain, stream, and recipient-quality signals that receivers associate with your mail, while the ESP manages the lower-level IP pool mechanics.
So yes: ramp volume on shared ESP infrastructure.
Just do it as a domain-and-stream introduction exercise, not as if shared IPs make sender reputation irrelevant.