One customer's sending problems should not become every customer's delivery problem. If your platform routes all its email through the same sending IPs, those customers share part of their reputation. IP pools let you separate that traffic, but splitting it too far can leave you with more IPs than your volume can support.
An IP pool is a named group of sending IP addresses. Your platform chooses which pool carries a message, so you can group customers deliberately rather than sending everyone through the same infrastructure.
This guide is for developers sending email on behalf of customers. The goal is to contain problems without creating a collection of underused pools that are harder to operate.
The short version
- Start with customer screening and sending controls. Pools do not replace either.
- Group customers by demonstrated sending behaviour, not just how much they pay.
- Keep new customers under observation. New does not mean abusive.
- Use a restricted path for legitimate customers fixing problems. Stop prohibited sending rather than giving it another pool.
- Create only as many pools as you can support with consistent traffic.
- Move customers based on evidence. A month on the calendar is not a reputation check.
Understand what a pool actually separates
Imagine a booking platform sending confirmations for many businesses. Most customers send expected messages to people who have just booked. One starts sending unwanted messages, and delivery problems begin affecting other customers using the same IPs.
That is the problem reputation-based pools are intended to mitigate. You decide which customers can share sending IPs and which should be kept apart.
There are several useful ways to divide traffic:
| Split | What it separates | Main trade-off |
|---|---|---|
| Traffic type | Transactional messages and marketing campaigns | Each stream needs appropriate infrastructure and enough steady traffic |
| Sender reputation | Established senders, new senders, and legitimate senders under restriction | Requires monitoring and rules for moving customers |
| Individual customer | One customer's traffic from everyone else's | That customer must support the IPs with its own steady volume |
| Volume | Customers with similar sending patterns or capacity needs | Volume alone does not tell you whether the sending is good |
For a beginner platform, our preferred starting point is reputation. Several steady, well-behaved customers can share a pool. A customer that needs closer supervision should not share the IPs your established senders depend on.
Traffic type is a separate decision. On PostShiba, transactional and marketing traffic belong on separate clusters and pools. A reputation tier should sit within the appropriate traffic type, not mix the two.
A pool is also not a complete isolation boundary. Your sending domain still matters, and creating a new pool does not repair the customer's recipient collection or sending practices.
Screen customers before assigning them a pool
The first protection is deciding what your platform allows.
Use a know-your-customer process, or KYC, to understand the business and its intended sending. For an email platform, that should include how recipients were collected and why they expect the messages. A verified domain alone does not answer those questions.
Before allowing external sending, ask:
- What does the customer’s product do?
- Which messages will it send through your platform?
- How did the customer collect the recipients?
- What volume and sending pattern should you expect?
- Can you stop this customer's sending without stopping everyone else?
Write down the answers and make them available to whoever reviews delivery problems. They give you a baseline for noticing when actual sending differs from the approved use case.
PostShiba does not allow bought, rented or scraped lists, cold outreach, or routing around another provider's rules. Our stance on cold email applies to every pool. A lower-reputation pool is not an exception to that policy.
Grow into a reputation-tier model
A tiered structure gives you somewhere to place customers as you learn about their sending. It is a model to grow into, not a requirement to create three pools on your first day.
| Tier | Who belongs there | Operating rule |
|---|---|---|
| Established, or Pool A | Approved customers with a demonstrated record of steady, expected sending | Protect this pool from unreviewed traffic |
| Restricted, or Pool B | Legitimate customers correcting a specific sending problem | Limit sending, require corrective action, and review progress |
| Observation | Approved new customers whose sending behaviour is not established | Start conservatively and collect evidence before promotion |
Pool A: established senders
Admission should mean more than passing onboarding. Look for a sending history that matches the approved use case, consistent volume, and no unresolved pattern of complaints or delivery failures.
Do not make the highest-volume customer automatically the most trusted customer. A large sender with poor recipient practices can be exactly the customer you need to keep out of this pool.
Pool B: restricted senders
Use this tier for a legitimate customer with an identifiable, correctable problem. For example, the customer may need to fix recipient collection or apply suppressions before you allow its normal volume again.
Require a recovery plan. Record what went wrong, what changed, what limits apply, and what evidence will support another review.
If the sending violates your policy, stop it. Do not move it to Pool B and treat the problem as contained.
Observation: new senders
New customers have limited history. That makes them uncertain, not automatically bad.
An observation tier gives approved customers a controlled starting point. Watch whether their actual recipients, volume, and delivery results match what they described during onboarding.
You can schedule a review after 30 days as an example. Do not automatically move every customer into Pool A on day 31. A customer that has barely sent anything has provided little evidence, however long its account has existed.
Do not create more pools than your traffic can support
Every split has a cost: less traffic remains available for each pool and each IP within it. Dedicated IPs need steady sending to build a useful history. Dividing an irregular workload across more addresses does not make that workload more consistent.
Our operating rule of thumb is to look for roughly 100,000 emails per day per IP before subdividing an established workload further. That is a planning heuristic, not a universal mailbox-provider minimum, a PostShiba requirement, or a guarantee of good delivery.
You can have a valid reason to separate traffic below that level. The point is to make the trade-off consciously, not to treat every new customer or reputation label as a reason to buy another IP.
Before creating a pool, answer four questions:
- What risk does this split contain? Name the customers or stream you are protecting.
- How much steady traffic will each IP actually carry? Use ordinary days, not just the largest campaign.
- What does the recipient-provider mix look like? Check whether the pool has regular traffic to the providers it needs to reach.
- Who owns warm-up and review? A pool needs an operating process, not just a name.
If volume is low or arrives in bursts, staying on shared IPs may be the better choice. Customer screening, per-customer limits, and the ability to stop an individual sender are still useful before dedicated reputation tiers make sense.
Low volume does not automatically cause a connection-limit error. A new or lightly used IP may need a cautious ramp, and a receiving provider may defer traffic. Read the provider's response before deciding whether the issue is volume, reputation, or something else.
Write the movement rules before moving customers
A useful pool structure needs an admission policy, a restriction policy, and a path back. Otherwise, moving customers becomes an improvised response to the latest complaint.
For each customer, review:
| Evidence | What to establish |
|---|---|
| Recipient acquisition | People have a reason to expect the messages |
| Complaints | Any recurring issue has been investigated and addressed |
| Bounces and suppressions | Known bad recipients are excluded and the source of failures is understood |
| Provider responses | Deferrals or blocks are understood, rather than hidden in a platform-wide total |
| Volume pattern | Sending is sufficiently steady for the destination pool |
| Corrective action | The customer has changed the behaviour that caused the restriction |
Treat these as review criteria, not a universal scoring formula. Complaint reporting and delivery evidence differ by provider. An absence of reported complaints is not, by itself, proof that every recipient wanted the mail.
For promotion, require meaningful sending history and a review of any previous problem. For restriction, record the reason, the limits, and the next review point. For abuse, suspend sending.
Do not move a problematic sender to fresh IPs just to get past a block. Moving pools is not a substitute for fixing the cause, and PostShiba prohibits routing around another provider's rules.
Keep routing under your platform's control
A pool policy only works if the platform decides which pool a customer can use. Store the customer's tier in your own system and map it to the appropriate pool when preparing a message.
Do not let a customer select the established pool simply by passing a pool name through your API. If customers can submit headers, enforce or replace the routing choice before sending.
PostShiba's IP pools feature routes individual messages using a header:
Here, established is an illustrative name for a pool you have created and attached to the sending cluster. The header works over SMTP, HTTP inject, and the REST API. Messages without it use the cluster's own IPs.
Named pools alone do not prove IP isolation. PostShiba allows an IP to belong to multiple pools. If Pool A and Pool B share the same IPs, you have not separated their IP reputation.
Check the membership of each pool, not just its label. Keep tenant-level controls as well: tenants organize customer resources, while pools choose sending IPs. You need both customer-level enforcement and deliberate routing.
Warm new IPs without undoing the separation
Moving established customers onto new IPs is still a warm-up exercise. Start with a controlled share, inspect the results by receiving provider, and increase traffic when the evidence supports it.
Do not move every customer at full volume simply because the new pool exists. Keep a record of the chosen sending route so your retry handling does not accidentally send the same message twice through different paths.
PostShiba also offers warm-up overflow. While every IP in a pool is warming, overflow can send excess traffic through the cluster's shared IPs.
That matters when your reason for creating the pool is isolation. A message assigned to a named pool may still leave through shared IPs during warm-up if overflow is enabled. Decide whether that fallback fits your policy, and check the actual sending IP in the message events.
The IP pool setup and warm-up guide covers pool creation, attachment, overflow, and delivery checks. Use it for implementation rather than treating the architecture diagram as proof that routing works.
Add the next pool only when you can explain it
Start with the smallest structure that protects your customers and fits your traffic. As volume grows, add reputation tiers or individual customer pools where they solve a specific problem.
Before adding another pool, write down its admission rules, expected daily traffic, IP membership, fallback behaviour, and review process. If those are unclear, you are not ready to operate it.
Map your current customers to established, observation, or restricted status before creating anything. Then calculate the steady traffic available to each group. That tells you which boundaries you can support now and which should remain customer-level controls until volume grows.
Sources and scope
- PostShiba: IP pool setup and warm-up, for pool behaviour, traffic types, shared sending, routing, overlapping IP membership, and overflow.
- PostShiba: IP pools announcement, for the message header and supported sending paths.
- PostShiba: our stance on cold email, for prohibited sending and customer-level enforcement.
The reputation tiers, 30-day review example, and 100,000-email planning heuristic are our proposed operating approach, not mailbox-provider requirements. Pool changes do not guarantee inbox placement.