# Shared IP: Definition and How It Works

Source: https://wraps.dev/glossary/shared-ip

Deliverabilityshared sending poolshared IP pool

A shared IP is a sending address used by many senders at once, whose reputation reflects the collective behavior of everyone in the pool rather than any single sender's own history.

## SES's default is a shared pool

Unless you provision a dedicated IP, SES sends every message through its own managed shared IP infrastructure. That pool already has an established, actively managed reputation across major mailbox providers, built from the aggregate sending behavior of everyone using it — which is why a brand-new SES account can send its first messages without going through an IP-warming period the way a fresh dedicated IP would need.

## Good behavior for you means good behavior for everyone in the pool

Because reputation is collective, a shared pool's health depends on AWS actively managing who uses it and how — monitoring bounce and complaint rates across the pool, and taking action against accounts that damage it. This is part of why AWS enforces bounce and complaint thresholds account-wide rather than leaving reputation entirely to market forces: a shared resource needs active moderation to stay usable for everyone on it.

## The trade-off is exposure to other senders' mistakes

In principle, another sender's bad behavior on the same shared IP pool could affect deliverability for everyone using it, which is the theoretical downside of shared infrastructure. In practice, AWS's pool management and scale reduce this risk considerably compared to a smaller or less actively managed shared pool, but it is not zero — it's the trade-off shared infrastructure makes for not needing warming or isolated reputation management.

## Right choice for most senders below dedicated-IP volume

For low or inconsistent sending volume, a shared pool's aggregate reputation is genuinely an advantage rather than a compromise — there's no volume threshold below which shared sending becomes a mistake, unlike a dedicated IP, which actively needs consistent volume to stay healthy. Most SES senders should stay on the shared pool by default and move to dedicated IPs only when volume and isolation needs justify it.

## Why it matters

The shared pool is why SES works reasonably well for a new sender on day one without a multi-week warming ramp — the alternative, provisioning everyone a cold dedicated IP by default, would make low-volume and early-stage sending dramatically harder than it needs to be.

## Common questions

### Do I need to warm up SES's shared IPs before sending at volume?

No. The shared pool already carries an established, actively managed reputation built from every sender using it, which is exactly why new SES accounts can send without a dedicated warming period.

### Can another sender on the same shared IP hurt my deliverability?

In principle yes, since reputation is collective, but in practice AWS actively monitors and manages who uses the shared pool and how, which considerably reduces the real-world risk compared to a smaller, less-managed shared pool elsewhere.

### At what volume should I move off the shared IP pool?

There's no fixed number, but roughly tens of thousands of consistent messages a month is where isolating your own reputation, or separating transactional from marketing traffic, starts to be worth a dedicated IP's cost and warming effort.