/ Capability 02 — Dedicated IPs
Dedicated IP email sending where the reputation is yours alone — warmed by engineers, isolated by stream.
Clean Tier-1 addresses, warming protocols an engineer tunes per receiver and watches daily, and reputation segmented by stream. The reputation you build is not diluted by senders you have never met — and we will tell you honestly if your volume is not yet high enough to make a dedicated IP worth it.
/ Quick answer
A dedicated IP is a sending address used only by you, so your inbox placement is built entirely on your own mail rather than the average of strangers sharing a pool. It pays off once you send consistently above roughly 100,000 emails a month with at least a few thousand a day. Below that, a dedicated IP can hurt you — there is not enough volume to keep it warm, and it goes cold between sends. A fresh IP needs four to six weeks of warming, ramped per receiver and watched daily, because a cold IP sending high volume reads to Gmail, Microsoft, and Yahoo exactly like a spammer. At Email Delivery Platform the warming is engineer-led, not a generic automatic schedule, and streams are isolated so a marketing campaign can never damage the IP that delivers your password resets.
-
~100k/mo
The volume threshold below which a dedicated IP usually hurts more than helps. Consistency matters as much as the number.
-
4–6 wks
Warming a fresh IP, ramped per receiver and watched daily. Rushing it is the fastest way to torch a new IP.
-
Yours alone
Reputation built only by your mail, insulated from the practices of every other sender in a shared pool.
-
Isolated
Transactional and marketing streams on separate IPs, so a low-engagement campaign cannot harm critical mail.
/ 01 — Reputation isolation
What does a dedicated IP actually give you?
A dedicated IP gives you one thing above all: reputation isolation. When you send from a shared IP, the receiving mail servers judge your mail partly on the collective behavior of everyone using that address. Your careful list hygiene and your strong engagement get averaged together with the practices of senders you have never met and cannot influence. If one of them sends to a stale list and triggers a wave of spam complaints, your inbox placement can drop without warning, and there is nothing you can do about it because the problem is not yours.
On a dedicated IP, that whole dynamic disappears. The address sends only your mail, so the reputation receivers attach to it reflects only your sending. The trade is that you now own both sides of that reputation — the upside when you send well, and the responsibility when you do not. There is no pool to hide in and no pool to be dragged down by. For a sender with the volume to build a strong reputation and the discipline to maintain it, that ownership is precisely the point: your deliverability becomes a function of your own choices rather than a lottery shared with strangers.
It helps to think of IP reputation the way you would a credit score. It is built slowly through consistent, responsible behavior, and it is far easier to protect than to repair once damaged. A new dedicated IP, like someone with no credit history, starts with no reputation at all — which is why receivers treat it with caution until it proves itself. That proving process is warming, and getting it right is the difference between a dedicated IP that becomes a durable asset and one that gets flagged in its first week and takes months to recover.
There is a second isolation benefit that matters as much as the first: predictability. On a shared pool, even when nothing goes wrong, your placement can shift as the mix of senders on the pool changes — a new high-volume sender joins, another leaves, the aggregate behavior moves, and your mail rides those movements without any change on your end. A dedicated IP removes that variable. Your placement reflects your sending and nothing else, which means when you change something and watch the result, the feedback is clean. That clean signal is what lets a serious sender actually optimize deliverability rather than guess at it through the noise of a shared pool.
/ 02 — The threshold
When does a dedicated IP help, and when does it quietly hurt?
This is the part most providers skip, because they would rather sell you a dedicated IP than tell you that you are not ready for one. The honest answer is that below a certain volume a dedicated IP does more harm than good, and the threshold is about consistency as much as raw numbers.
The mechanism is simple. A dedicated IP holds reputation only as long as it sends consistently. Receivers evaluate recent behavior, so an IP that sends a burst and then goes quiet for days loses the standing it built, and the next send is treated almost as if from a cold IP again. To keep a dedicated IP warm, you need enough steady volume — generally above roughly 100,000 messages a month, with at least a few thousand on a typical day — that the IP never gets a chance to cool down between sends.
Below that threshold, a shared pool is the better choice precisely because it is always warm. The aggregate volume of every sender on the pool keeps its reputation alive, so your occasional or lower-volume sending benefits from a warmth you could not maintain alone. Moving such a sender onto a dedicated IP strips away that benefit and replaces it with an IP that is perpetually half-cold, delivering worse placement than the shared pool it left. The dedicated IP is the right tool above the threshold and the wrong one below it, and knowing which side you are on is the first decision to get right.
There is a related question once you are above the threshold: how many dedicated IPs you actually need. More is not better. Each IP needs enough volume to stay warm on its own, so splitting a given volume across too many addresses leaves each one underfed and weak. The right number is the fewest IPs that let you isolate the streams that matter while keeping every IP comfortably above its own warmth threshold. We size that allocation to your real volume and stream structure rather than handing you a default count, because an IP without enough mail to sustain it is worse than no dedicated IP at all.
| Dimension | Shared IP | Dedicated IP |
|---|---|---|
| Whose behavior affects you | Every sender in the pool | Only your own |
| Reputation control | None — you inherit the average | Full — you build it |
| Warming required | No (pool is already warm) | Yes (4–6 weeks) |
| Best for volume | Below ~100k/month | Above ~100k/month, steady |
| Blast-radius of a mistake | Shared across pool | Contained to your streams |
/ 03 — Warming
How does warming a fresh IP actually work?
Warming introduces a new IP to receivers gradually, so they can see legitimate, engaged traffic building over time rather than a sudden flood that looks like spam. The ramp below is illustrative — every sender's curve is shaped to their real volume and engagement — but the shape is consistent: start low, accelerate only on green signals.
| Phase | Volume | What happens |
|---|---|---|
| Day 1–3 | 50 / day | Seed to most-engaged recipients only |
| Week 1 | 1k / day | Gmail + Microsoft prioritized, Yahoo held back |
| Week 2 | 10k / day | Ramp doubles every 2–3 days if signals stay green |
| Week 3–4 | 100k / day | Full receiver coverage, engagement monitored |
| Week 5–6 | Target | Stabilize at your real volume curve |
What makes our warming different from an automatic schedule is that an engineer watches the postmaster feedback daily and adjusts in real time. A generic ramp doubles volume on a fixed calendar regardless of how receivers respond; engineer-led warming holds back when a receiver shows hesitation and accelerates when the signals are clean. The schedule is a starting point, not a script, because the receivers ultimately decide the pace and reading their signals correctly is the whole skill. A sender who follows a calendar blindly will eventually push volume into a receiver that was signaling caution, and that single misread is often enough to set the warming back by weeks. Watching and responding is not a nicety layered on top of the schedule; it is the part that actually determines whether the warming succeeds.
/ 04 — Stream isolation
Why transactional and marketing mail belong on different IPs.
Transactional mail and marketing mail have fundamentally different engagement profiles, and that difference is why they should not share an IP once you have the volume to separate them. A password reset or an order receipt is opened almost every time, often within minutes, because the recipient is waiting for it. A marketing campaign or newsletter, however good, sees lower and more variable engagement — some recipients open, many do not, and a few mark it as spam. Receivers read those engagement signals as reputation, and they read them per IP.
When both streams share one IP, the lower-engagement marketing mail drags on the reputation of the IP that also carries your critical transactional mail. A campaign that underperforms, or a list segment that generates complaints, can degrade the placement of the password resets and receipts your customers genuinely need. Those transactional messages are the ones where a trip to the spam folder causes real damage — a customer who cannot log in or cannot confirm an order — so protecting their deliverability is worth the cost of a separate IP.
Stream isolation puts each type of mail on an IP whose reputation reflects only that stream. The transactional IP stays pristine because it carries only high-engagement mail; the marketing IP carries the variable engagement without contaminating anything critical. We set this up as part of provisioning at sufficient volume, because retrofitting stream separation after a reputation problem has already crossed between streams is far harder than designing it in from the start.
The same logic extends past the transactional-versus-marketing split when volume justifies it. Different marketing programs with very different engagement — a re-engagement campaign to a dormant segment versus a newsletter to active subscribers — can themselves warrant separation, so the riskier sending never threatens the reputation of the reliable kind. How far to take stream separation is a judgment about your specific sending and volume, and it is one we make with you during setup rather than applying a rigid template. The principle stays constant: keep your most valuable, highest-engagement mail on an IP that nothing lower-engagement can drag down.
/ 05 — The full setup
A dedicated IP is more than an address — the setup around it.
An IP address alone delivers nothing. What makes a dedicated IP work is the configuration around it, all of which we provision and maintain so the address arrives ready to send.
# What a production-ready dedicated IP requires
PTR / reverse DNS -> ip resolves to your sending hostname
A record -> hostname resolves back to the ip (FCrDNS)
SPF -> the ip authorized in your domain's policy
DKIM -> messages signed; keys rotated on schedule
DMARC -> alignment enforced and reports monitored
Tier-1 allocation -> clean address with no prior blocklist history
# Forward-confirmed reverse DNS (FCrDNS) — both directions
# must agree, or major receivers distrust the IP on sight. The detail receivers care about most here is forward-confirmed reverse DNS: the IP must resolve to a hostname, and that hostname must resolve back to the IP. A mismatch is one of the fastest ways to have mail distrusted before content is even evaluated. Allocating a clean Tier-1 address matters too — an IP with a history of abuse from a previous occupant arrives already carrying a reputation problem, which is why we allocate from clean ranges rather than recycling addresses with unknown pasts.
/ 06 — Ongoing care
Warming is the start — reputation is maintained, not set once.
A common misconception is that warming finishes and the dedicated IP is then done. In reality, warming is only the beginning of the relationship between your IP and the receivers. A dedicated IP's reputation is a living thing that responds continuously to how you send: a spike in complaints, a run of hard bounces from a stale list segment, a sudden change in volume, or a content shift that trips spam filters can all move it. The reputation you spent six weeks building can erode in days if the sending that follows is careless, which is why the work does not stop when the ramp completes.
Day-to-day, that means watching the signals that receivers expose: bounce rates by receiver, complaint rates from feedback loops, the appearance of your IP on any blocklist, and the placement of seed messages across the major inbox providers. When one of those signals drifts, the value of operating at the infrastructure level is that we can act on it directly — slow the IP, adjust shaping toward a specific receiver, pause a problematic stream, or reach a postmaster contact — rather than just reporting that something looks wrong and leaving you to figure out the fix.
This ongoing care is also where a dedicated IP and a managed service naturally meet. The IP gives you isolated reputation; the management keeps that reputation healthy over time. You can run a dedicated IP without managed operations, watching the signals yourself, but the two together are what turn a dedicated IP from a liability you have to babysit into an asset that quietly does its job. The address is yours alone, and so is the responsibility — but the responsibility is one you can hand to a team that does only this.
The cost of neglecting that responsibility is asymmetric, which is what makes ongoing care worth it. Building reputation is slow and incremental; losing it can be fast and steep. A single bad send to a large stale segment can generate enough complaints to undo many weeks of careful, patient warming, and recovering from a serious reputation hit almost always takes far, far longer than the damage itself originally took to inflict. That asymmetry — slow to build, quick to lose, and slow once again to repair — is the entire reason a dedicated IP rewards constant, ongoing attention rather than occasional, after-the-fact checking. The senders who get the most from dedicated IPs are the ones who treat reputation as something to defend every day, not a milestone they passed during warming and then stopped thinking about.
/ Common questions
What teams ask about dedicated IPs.
When do I actually need a dedicated IP?
Generally once you are consistently sending above roughly 100,000 to 200,000 emails per month from a stable sender domain, with at least a few thousand a day. Below that, a dedicated IP can actually hurt you — there is not enough volume to maintain a warm reputation, and the IP goes cold between sends, so receivers treat each batch as if from a stranger. Above that threshold, a dedicated IP lets you build and protect a reputation that is entirely your own, insulated from the behavior of every other sender. The threshold is about consistency as much as raw volume: steady daily sending warms and holds reputation, while sporadic bursts never let it stabilize.
How long does IP warming take?
Four to six weeks for a fresh IP targeting meaningful daily volume, though some receivers reward good behavior with a usable reputation in around two weeks while others take the full six. The ramp follows receiver-specific schedules because Gmail, Microsoft, and Yahoo each respond differently to volume increases. We start low — on the order of fifty to a few hundred messages on day one — watch postmaster feedback daily, and accelerate only when reputation signals stay green. Rushing warming is the single most common way senders torch a new IP, because a cold IP sending high volume reads to receivers exactly like a spammer.
What is the difference between shared and dedicated IPs?
On a shared IP, your sending reputation is the average of everyone using that address — including senders you have never met whose practices you cannot control. One bad actor in the pool can drag your inbox placement down with no warning and nothing you can do about it. On a dedicated IP, the reputation is built only by your mail. You own the upside and the responsibility, which is exactly what you want at scale, because at scale you have the volume to build a strong reputation and the most to lose from someone else's mistakes diluting it.
Can we segment IPs by email type?
Yes, and at sufficient volume you should. We routinely separate transactional mail — receipts, password resets, alerts — from marketing mail like campaigns and newsletters, onto different IPs. The two have very different engagement profiles: transactional mail is opened almost universally, while marketing mail engagement is lower and more variable. Mixing them on one IP lets a low-engagement campaign damage the reputation that delivers your critical transactional mail. Stream isolation keeps the IP that sends your password resets clean regardless of how a marketing send performs.
Does the domain reputation matter as much as the IP?
Both matter, and they are separate. Receivers, Gmail especially, have placed growing weight on domain reputation because it follows a specific sender even across IP changes, whereas IP reputation is tied to the address. A dedicated IP gives you control over the IP half; consistent authenticated sending from a stable domain builds the other half. The two reinforce each other, which is why warming a dedicated IP works best alongside a domain that is already sending in a steady, authenticated pattern rather than a brand-new domain starting cold at the same time.
What happens to my dedicated IP if I stop sending for a while?
It goes cold, and reputation decays. IP reputation is not a permanent score you earn once; it reflects recent behavior, so a dedicated IP that sits idle gradually loses the standing it built. If you resume at full volume after a gap, receivers may treat the sudden traffic with suspicion, much as they would a cold IP. This is part of why dedicated IPs suit consistent, ongoing senders rather than occasional ones — the reputation is only as warm as your recent sending keeps it.
A reputation that is yours alone — warmed properly, watched daily.
Talk to our deliverability team about dedicated IPs: whether your volume justifies one yet, how warming would be staged for your sending, and how we would isolate your streams. If a shared pool still serves you better, we will tell you that instead.
Book infrastructure reviewRelated capabilities