Shared vs dedicated IP for cold email — which should you use?

For nearly every cold outreach programme, the shared outbound addresses behind Google Workspace and Microsoft 365 are the right answer, and the reason is arithmetic rather than preference. A dedicated IP is not a setting you enable; it is a standing commitment to feed one address enough mail that receivers keep remembering it. Postmark puts the floor at 300,000 messages a month. Amazon SES advises 1,000 messages a day to each provider you care about, per address, after warm-up. Work out what your fleet actually sends before you buy anything.

The decision is a volume commitment, not a preference

An IP address earns a reputation the same way a domain does, by sending mail that people want, consistently, for long enough that receivers form an opinion. The difference is that a domain accumulates that history across every channel it sends on, while an IP accumulates it only from what physically leaves that address.

That creates a threshold effect nobody advertises. Below some volume, a receiver simply does not see enough traffic from an address to distinguish it from noise, and an unknown address is treated conservatively. Above it, the address has a track record and the shared pool's behaviour stops mattering to you. The two published figures below are the industry's own estimates of where that threshold sits, and they are the numbers to reason with rather than any generic advice about "high volume".

The mistake is treating a dedicated IP as insurance. It is closer to a lease with a minimum usage clause: cheap to sign, expensive to under-use, and the penalty is exactly the outcome you bought it to avoid.

What a dedicated IP costs, in money and in messages

Amazon SES publishes both halves of this, which makes it the cleanest example to reason from even if you send elsewhere.

Money. A standard dedicated IP address is $24.95 per month per address. The managed option is $15 per month per account plus a per-email fee that starts at $0.08 per 1,000 messages and falls with volume. Both sit on top of the base outbound rate of $0.10 per 1,000 emails. Bringing your own address range has a documented minimum of 256 addresses, which AWS prices at $6,387.20 per month.

Time. SES warms new standard dedicated addresses automatically, and the mechanism is worth reading precisely: "Automatic IP warmup is a time-based process. The warmup percentage steadily increases over 45 days, independently from your sending volume." During that window SES splits your sending between the new dedicated address and shared addresses. Separately, AWS notes that building a positive reputation takes "around two weeks" with some providers and "up to six weeks" with others.

Messages, forever. This is the clause people skip. AWS: "After you warm up a dedicated IP address, you should send around 1,000 emails every day to each email provider that you want to maintain a positive reputation with. You should perform this task on each dedicated IP address that you use with SES."

Postmark states the requirement as a monthly figure: a dedicated IP requires at least 300,000 messages a month, because "this kind of volume is the best to establish an IP's reputation, so that each receiver actually knows and remembers who you are". Postmark also publishes the decay rule — if volume falls below 20,000 messages a week for four weeks, the address goes through warm-up again.

The arithmetic on a real cold outreach programme

Put a plausible fleet against those numbers. Ten connected mailboxes, each sending 40 messages a day, Monday to Friday. That is a deliberately healthy cold configuration, not a throttled one.

• Per day: 10 × 40 = 400 messages.
• Per month: roughly 21.7 working days × 400 = 8,680 messages.
• Against Postmark's floor: 8,680 ÷ 300,000 = 2.9% of the stated minimum.
• Against the AWS maintenance figure: if 40% of your list is on Gmail, that address sends 160 Gmail messages a day. AWS suggests 1,000 per provider — you are at 16%, and that is before splitting the remainder across Microsoft, Yahoo and everyone else.

To clear 300,000 messages a month at 40 a day per mailbox you would need roughly 346 mailboxes sending every working day without pause. If your programme is genuinely that size, this article is not aimed at you and the calculus is different. If it is not, a dedicated IP means paying $24.95 a month to send from an address that no receiver sees often enough to trust, having first spent 45 days getting there.

Run the same sum for a fleet you are still building and the gap widens rather than closes. A new mailbox does not open at 40 a day — it ramps, and during the ramp its effective ceiling is a fraction of its configured limit. A fleet of ten mailboxes that all start together spends its first three weeks producing well under 400 messages a day in aggregate, which is precisely the window in which a freshly leased dedicated address is also being warmed. Two warm-ups running against each other, each starving the other of the volume it needs, is the worst configuration available. The free email warmup planner models the fleet-size against time-to-volume tradeoff in the browser if you want to see the curve before committing to either.

There is a second-order cost too. Concentrating a fleet's output onto one address defeats the load spreading that mailbox rotation exists to provide, and what actually breaks first as an outbound fleet grows is rarely the IP.

One hybrid deserves a mention because it is often the honest middle. Most relay providers let you group addresses into pools and route different traffic classes down different pools, so transactional mail can sit on a dedicated address while cold outreach stays on shared infrastructure. That splits the volume commitment across the traffic that can actually meet it. It also makes the reverse arrangement visible for what it is: putting your cold volume on the dedicated address and your transactional mail on shared is the allocation that maximises risk and minimises benefit, and it is the one people back into by accident.

On a shared provider IP you cannot see the reputation — or change it

This is the honest disadvantage of shared infrastructure, and it deserves to be stated without softening.

Microsoft's Smart Network Data Services is the only real IP-level instrument for Microsoft's consumer estate, and access is granted by proving ownership of an address range. Microsoft verifies against reverse DNS, RDAP and the global routing table, then sends an authorisation link to a contact registered against the range — typically abuse@ or postmaster@ at the registrant's domain. Microsoft 365 and Google Workspace outbound addresses are registered to those companies. The authorisation email goes to them. There is no manual review path; the system is automated end to end.

Google Postmaster Tools does publish an IP Reputation dashboard alongside Domain Reputation, on the same four bands: High ("History of very low spam rates, and complies with Gmail's sender guidelines"), Medium ("History of sending legitimate email, but occasionally sends spam"), Low and Bad. For a Workspace sender, the addresses being rated are Google's own. The number is real; it is not about you.

So the trade is precise. On shared provider infrastructure you get no IP-level visibility and no IP-level control, and in exchange you inherit an address pool that Google and Microsoft have every commercial reason to keep in good standing. On a dedicated address you get full visibility and full control of a reputation you must then feed daily. Neither is free.

Autocloz's free plan covers 5 users and 10 mailboxes with warmup ramping, on-demand placement tests and SPF, DKIM and DMARC monitoring — start free and connect the mailboxes you already own rather than buying infrastructure you will underuse.

What actually carries your reputation on shared infrastructure

Look at what the shared pools contain and the answer becomes obvious. Measured on 9 September 2026, spf.protection.outlook.com publishes ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17 plus IPv6 ranges, ending -all. Every Microsoft 365 tenant on earth sends from inside that set. _spf.google.com publishes ip4:74.125.0.0/16 ip4:209.85.128.0/17 plus IPv6, ending ~all, for every Workspace customer.

No receiver can usefully rate you on an address shared by millions of organisations. So the signals that do the work are the ones that are yours:

• The domain in the visible From header, which Google rates separately on the same four-band scale.
• The DKIM signing domain, the d= value in the signature. Postmaster Tools computes its spam rate over DKIM-authenticated messages, which ties the receiver's most consequential number to the domain that signed rather than the address that connected.
• Your complaint rate, which Google asks bulk senders to keep below 0.30% and, as a target, below 0.10%.
• Your bounce rate and list hygiene, because a hard bounce is one of the few signals every receiver agrees on.

The bulk-sender requirement for forward and reverse DNS is worth a line here, because it is the one item on Google's list that genuinely is IP-level. On Google Workspace or Microsoft 365, the PTR records for the outbound addresses are the provider's responsibility and are already correct. Take a dedicated address and that becomes your job, in the registrant's DNS, and getting it wrong is a rejection you will spend a day diagnosing.

The shared-neighbours objection, examined properly

The argument for a dedicated address is usually stated as neighbour risk: another sender on your pool behaves badly and you inherit the damage. It is not wrong, but it is applied at the wrong scale.

The risk is real on small, loosely policed shared pools — a low-cost relay with no sender vetting concentrates bad behaviour on a handful of addresses. It is much weaker on Google Workspace and Microsoft 365, where the pools are enormous, the tenants are paying and identifiable, and both companies operate abuse enforcement because the reputation of their own outbound estate is a product feature.

There is also a rarely-noted asymmetry in your favour. On a shared pool, a bad day of yours is diluted too. A batch of 200 hard bounces is a meaningful event on a dedicated address sending 8,000 a month, and statistically invisible inside Google's outbound volume. If your programme is still learning, that dilution is a benefit rather than a compromise.

Where the objection genuinely bites is a low-cost bulk SMTP relay used for cold outreach. That is the configuration with the worst of both worlds: shared addresses you cannot inspect, pooled with senders nobody vetted. If that describes your setup, the fix is a better provider, not a dedicated address on the same one — and which relay and mailbox providers are worth connecting is a more consequential decision than shared versus dedicated.

When a dedicated IP genuinely is the right answer

Scope this honestly, because the answer is not "never".

• Sustained volume well past the published floors — comfortably above 300,000 messages a month, with a daily rate that does not collapse between sends.
• Consented, engaged recipients rather than cold prospects, so complaint rate is structurally low and the reputation you build is worth isolating.
• Separation you actually need, such as keeping transactional receipts away from marketing volume so a promotional complaint spike cannot delay a password reset.
• A brand large enough to be a target, where receivers benefit from being able to identify your traffic precisely.
• An operator who will watch it. A dedicated address needs a monitored reputation dashboard, a feedback loop and someone who reacts. Unwatched, it is a liability with a monthly invoice.

If you connect Amazon SES as a sending provider, all of the above is available and priced in the open, which is why SES makes the tradeoff easy to reason about even for teams who end up declining it.

The counterpart question — how much volume any one mailbox can carry before its own provider limits bind — is answered by the per-provider sending limits, and that ceiling usually binds long before an IP decision matters.

What an IP decision cannot fix, and what Autocloz does not do

An IP address is one input among several, and it is the one with the least leverage for cold outreach. A dedicated address does not repair authentication, does not verify a list, does not reduce complaints, and does not make an unwanted message welcome. If placement is poor with correct SPF, DKIM and DMARC and a clean list, changing the address underneath will not move it.

Warming an address and warming a domain are also different jobs with different clocks, and doing one does not do the other — what IP warm-up actually involves is a separate procedure from a mailbox ramp.

And Autocloz specifically. It does not sell, lease or manage IP addresses. It connects mailboxes you already own — Google Workspace, Microsoft 365, generic SMTP and IMAP, Amazon SES and other relays — and whatever address those send from is your provider's decision, not a setting inside Autocloz. It has no dedicated-IP product, no IP pool and no IP warm-up schedule; the warmup ramp it does run shapes volume per mailbox, which is a different control. It cannot show you SNDS data for an address you do not own, because nobody can. And it cannot see the reputation of a shared pool any more than you can, so a placement result on a shared provider tells you about the outcome and never about which of the pool's tenants caused it.