Plan your IPs and pools.

Shared IPs are the right default. Dedicated IPs and pools are how you split reputation once volume is steady. This lesson covers when to stay shared, the four setups that work, and the rules PostShiba uses when a message names a pool.

Shared or dedicated

Every cluster starts on shared IPs. PostShiba keeps them warm with traffic from many senders. A new sender on a shared cluster can deliver from the first message. Your domain reputation still matters.

A dedicated IP is a sending address only your team can use. You add it from Network for $50 a month, then assign it through a cluster's Sending IPs or an IP pool. Clusters themselves are always created on shared IPs. Customer clusters stay shared until you buy an add-on.

Stay on shared IPs when you send under about 50,000 messages a month, or when volume comes in bursts. A dedicated IP that sends a few hundred messages one week and nothing the next looks like a spammer. Buy one when a stream is large, daily, and worth a reputation of its own, or when a recipient needs a fixed address to allowlist.

A cluster holds at most one dedicated IP of its own. To send on more than one, put them in a pool. Extra shared IPs are $15 a month if you only need more shared capacity.

Four setups

Most teams land in one of these four. Transactional and bulk never share a cluster or a pool.

Sketch a setup below, then read how the pieces attach.

Rules of thumb

Stay shared until volume is steady. Warm-up only pays off if the IP will keep sending every day after day 14.

Put two IPs in a pool you depend on. If one address has trouble at a provider, the other keeps the pool sending.

Do not spread thin. Each IP should carry real daily volume. Add IPs as volume grows, not before.

Keep risky mail apart. A new customer, or a list you have not mailed in months, belongs on shared IPs or in its own pool. Never drop it into a pool other mail depends on.

Use a pool when you need more than one dedicated IP. The cluster's Sending IPs slot holds a single dedicated address. The pool is how 198.51.100.10 and 203.0.113.10 share a name.

How pools work

An IP pool is a named set of your dedicated IPs. Mail opts in one message at a time with the X-Capsule-Pool header. Mail without the header keeps using the cluster's own IPs, the default pool.

A pool is transactional or bulk. That cannot change. It only takes IPs and clusters of the same type.

Each IP has a weight from 1 to 100. Weights are relative. They do not need to add up to 100. Two IPs at 100 and 50 take two thirds and one third of the pool's mail.

One pool can be attached to several of your shared clusters, as long as they match the pool's type. One IP can sit in several of your pools. An IP sends from a cluster's default pool or from pools, never both. Mail without the header never leaves on a pool IP.

The name you send in X-Capsule-Pool is the pool's name. Use lowercase letters, numbers, dashes, and underscores. For a customer pool, the tenant slug works well. default means the default pool. The header is not case-sensitive, and PostShiba removes it before the message leaves.

A pool name that does not exist, is not attached to the cluster, or has no live IPs is refused. That mail never falls back to the shared IPs. On SMTP the reply is 550 5.7.1 X-Capsule-Pool is not a sending pool on this cluster. On REST you see 502 inject_failed. If you detach or empty a pool while mail for it is queued, that mail waits and is retried. It does not slip onto the default pool.

To pin one message to a specific address, send X-Capsule-Ip: 203.0.113.10. The IP must be one of that cluster's sending IPs, or an IP in a pool attached to the cluster. Any other address is rejected. With both headers, the IP must be in that pool. Both headers are stripped before the message leaves.

Pool mail counts toward the cluster's hourly throttle and 24-hour cap.

While every IP in a pool is still warming, the pool can only take part of its mail. With Use the cluster's IPs while warming up on, the default, the rest goes out on the cluster's default pool. That is overflow doing its job. The warm-up lesson covers the 14-day window and the ramp after it.

Add capacity and retire IPs

When a warm pool needs more room, buy an IP and add it at a low weight. While it warms it takes its small daily share. The warm IPs carry the rest. After day 14, raise the weight a step every few days: 10, then 25, then 50, then 100. Check bounces, spam reports, and deferrals before each step.

Calling add_ip again on an IP already in the pool only changes its weight.

To retire an IP, remove it from the pool. Queued mail pinned to it goes out on the rest of the pool. You still own it and pay for it until you cancel it in Network. A cancelled IP rests for 30 days before another team can buy it, and the next owner warms it from the start. You cannot cancel an IP that is the only sending IP on one of your clusters.

If a stream shrinks, take IPs out rather than leaving half-idle addresses in the pool. Quiet IPs lose reputation over a few weeks.

Setup in five calls

The IP pool guide has every curl. The shape is five calls, then you send.

1. Buy dedicated IPs from Network with POST /api/v1/teams/:team_id/network. Leave out cluster_id so each IP stays free for the pool. Warm-up has not started yet.
2. Create the pool with POST /api/v1/teams/:team_id/ip_pools. Set name, classification, and warmup_overflow: true.
3. Add each IP with POST /api/v1/ip_pools/:id/add_ip and a weight. Status becomes warming and warmup_ends_at is 14 days out.
4. Attach the pool to each shared cluster of the same type with POST /api/v1/ip_pools/:id/attach. The pool shows Ready when it has an IP and a cluster.
5. Send with X-Capsule-Pool: receipts (or your pool name) on REST, SMTP, or HTTP inject. A Send only key is enough for this header.

Use a Full access key in your shell for steps 1 to 4. Changing Network in the dashboard needs the Team Administrator role. Import suppressions before step 5. Then warm on the guide's schedule and wire the rest of the account.