PowerMTA IP pools & rotation, done the legitimate way

"IP rotation" gets a bad reputation because spammers abuse it. Done correctly, it's simply how high-volume senders spread load and reputation across several clean IPs instead of overloading one. This page covers the legitimate use in PowerMTA — and is blunt about the use that will get you blacklisted. The mechanics are simple; the discipline of using them honestly is what separates a healthy multi-IP setup from a fast route to a blocklist.

Building a pool

Create a virtual MTA per clean IP (see vMTAs), then group them:

<virtual-mta-pool pool-marketing>
    virtual-mta vmta-1
    virtual-mta vmta-2
    virtual-mta vmta-3
</virtual-mta-pool>

<virtual-mta-pool pool-transactional>
    virtual-mta vmta-tx-1
</virtual-mta-pool>

PowerMTA distributes mail across the IPs in a pool. Route each stream to its pool with the X-Virtual-MTA header or a source's default-virtual-mta.

How rotation actually works

Within a pool, PowerMTA distributes mail across the member vMTAs in round-robin fashion — each new message takes the next IP in turn, so volume spreads evenly rather than piling onto one address. If a single vMTA itself holds multiple IPs (you can list more than one smtp-source-host), PowerMTA picks one of those at random per message. Either way, the effect is the same: load and reputation are shared across the addresses in the pool instead of concentrated.

A point that trips people up: the outgoing IP is not chosen by the sender’s domain or address. It’s decided entirely by which pool or vMTA the message is routed to. If every message keeps leaving from the same IP when you expected rotation, the cause is almost always that the source’s default-virtual-mta points at one vMTA rather than the pool — not a bug in rotation. Get the routing right and the round-robin does the rest.

Routing mail to a pool

There are three ways a message ends up on a given pool, and they form a clear precedence. Most explicit is the X-Virtual-MTA header, which your application or MailWizz sets per message to name the pool or vMTA — this is how you assign a specific campaign or stream to a specific pool. If no header is present, the submitting source’s default-virtual-mta applies, so all mail from one feed defaults to one pool. And default-virtual-mta by-smtp-source-ip selects the vMTA whose IP matches the address the message arrived on — useful when the feeding system already connects on the right IP.

The practical pattern is to set a sane default-virtual-mta on each source so nothing is ever unrouted, then override per message with X-Virtual-MTA where a particular send needs a particular pool. That gives you a safe default and precise control where it matters, without having to tag every single message.

Separate streams, isolated reputation

The single most valuable thing a pool gives you is isolation. Keep transactional and marketing apart:

Stream	Pool	Why
Transactional	pool-transactional	Highest engagement; must reach the inbox; protect it
Marketing	pool-marketing	Lower engagement; isolate so it can't drag down resets/receipts

Pool design patterns

Beyond the basic transactional/marketing split, a few patterns recur once you’re running real volume. The most common is by stream — transactional, marketing and notifications each on their own pool — because each has a different engagement profile and risk level, and isolating them stops a low-engagement stream from pulling a high-trust one into spam. This is the highest-impact split for most senders.

Two others are worth knowing. By reputation tier keeps a warm, established pool separate from a pool of newer IPs still warming up, so you can ramp new addresses without exposing your main reputation to their cold start. By customer or tenant matters if you send on behalf of multiple clients — separate pools mean one client’s bad list can’t damage another’s deliverability. Each pattern is the same principle applied along a different axis: put things whose reputations should not affect each other on different IPs.

Pair pools with separate sending subdomains for each stream where you can, since domain reputation travels alongside IP reputation — marketing from mail.example.com and transactional from tx.example.com, each on its own pool, isolates both layers at once. The pool handles the IP side; the subdomain handles the domain side; together they keep the streams genuinely independent.

Warm before you add

A new IP added straight into a busy pool sends cold mail and earns a bad first impression. Warm it gradually — small, engaged volume ramping over days and weeks — before it shares full load. Reputation is built per IP; a pool doesn't hand it out for free. Once warm, pools let you scale without concentrating risk on a single address.

PowerMTA can enforce the ramp for you. The max-cold-virtual-mta-msg directive caps how much a cold vMTA sends per day, and auto-cold-virtual-mta marks a new IP as cold so the cap applies until it’s earned trust. A new IP in a pool can be held to a small daily volume while the warm IPs carry the rest:

<virtual-mta vmta-new>
    smtp-source-host 203.0.113.30 new.example.com
    auto-cold-virtual-mta 203.0.113.30 new.example.com
    <domain *>
        max-cold-virtual-mta-msg 100/day    # cold cap until warm
    </domain>
</virtual-mta>

Raise the cap as the IP ages and its reputation builds, then retire the cold marking once it’s carrying full load cleanly. This is the per-IP enforcement behind the warm-up discipline described in dedicated vs shared IP — the pool spreads the load, the cold cap keeps a new member from sending more than its young reputation can support.

Sizing a pool

The right number of IPs in a pool is “enough to carry your volume without overdriving any single one, and no more than you can keep warm.” Those two limits matter equally. Too few IPs and each is pushed past the rate a provider tolerates, drawing deferrals; too many and each one sends so little that none builds a stable reputation — a fleet of half-idle IPs is weaker than a handful of busy ones, because reputation rewards consistent, sufficient volume.

So size the pool to your real, sustained, opt-in volume, not to how many IPs you could buy. If you’re sending modestly, a small pool of well-warmed IPs outperforms a large sprawling one every time, and it’s cheaper to keep healthy. Add IPs when consistent volume genuinely outgrows the current set — and warm each new one before it shares the load — rather than provisioning ahead of demand and leaving addresses cold. The pool should grow in response to volume, not in anticipation of it.

Why this is not evasion

It’s worth being explicit about the line between legitimate rotation and the abuse that gives it a bad name, because the difference is intent and it’s visible to providers. Legitimate pools distribute the sending of mail people asked for across clean IPs, so no single address is overdriven. Abusive rotation cycles through fresh IPs to keep sending mail that’s generating complaints, trying to outrun the reputation damage — which is exactly the pattern blocklists and mailbox providers are built to catch.

Providers correlate sending behaviour across IPs and domains, so spraying a bad list over fresh addresses doesn’t hide it — it spreads the damage and burns every IP involved, often the domain too. There is no IP-count trick that fixes a consent or content problem; the only fix for filtering is better authentication, cleaner lists and real engagement. Pools are reputation hygiene for wanted mail. Used as evasion, they accelerate exactly the outcome you were trying to avoid, which is why this site won’t help configure them that way.

Monitoring pools and rotating out a bad IP

A pool isn’t set-and-forget, because individual IPs drift. Watch each member vMTA’s deliveries, deferrals and bounces — PowerMTA’s queue and status views break this out per vMTA — alongside per-IP signals from provider dashboards like Postmaster Tools and SNDS. Because each IP is its own identity, a problem usually shows up on one member before it affects the pool’s overall results, giving you time to act.

When one IP goes bad — a rising bounce rate, a blocklist hit, a reputation dip — the pool gives you a clean response: pause or remove that vMTA from the pool while you investigate, and the round-robin simply routes around it across the remaining healthy IPs. You diagnose and rehabilitate the one address (or retire it) without interrupting the stream, then warm it back in. That ability to isolate and treat a single IP without taking the whole stream offline is one of the quieter benefits of running a pool rather than a single address.

KumoMTA egress pools

KumoMTA expresses the same idea as egress pools built from egress sources. An egress source binds a sending IP and HELO host (the vMTA equivalent); an egress pool groups several of them; and Lua routing logic decides which pool a message uses, with weighting and selection you control in code. The round-robin-style distribution, the per-stream separation, the warm-up handling — all the concepts carry over.

If anything, KumoMTA’s Lua model makes complex routing more programmable, since the pool a message takes can be decided by arbitrary logic rather than a header or a fixed default. The trade-off is the usual one: more power and more rope. Whichever engine you run, the design principles on this page — separate streams, warm new IPs, size to real volume, never rotate to evade — apply unchanged, and the Auto PMTA Configurator builds pools for either.

Pools, vMTAs and domain policy together

Pools are one layer of PowerMTA’s control, and they work best understood alongside the other two. A vMTA defines a single sending identity; a pool groups identities so traffic spreads across them; and domain policy governs how hard you push each receiver. The three compose: a stream routes to a pool, the pool spreads it across vMTAs, and domain policy shapes the rate to each provider regardless of which IP a given message used.

Seeing them as layers keeps each one simple. You don’t encode rate limits into pools or stream separation into domain blocks; each layer does its job, and together they give the “layered control” that makes PowerMTA predictable. Design the pools for who sends what, the vMTAs for which IPs exist, and the domain policy for how fast to push each receiver — and the whole setup stays legible.

Common pool mistakes

The recurring errors are avoidable. Mixing streams — marketing and transactional in one pool — lets a rough campaign sink your password resets. Adding cold IPs to a busy pool without a cold cap sends fresh addresses at full volume and burns their first impression. Oversizing spreads volume so thin no IP builds reputation, and undersizing overdrives each IP into deferrals.

The two that cause the most lasting damage are routing everything to one vMTA by accident (a misconfigured default, so “rotation” never happens) and, of course, rotating to evade a filtering problem instead of fixing its cause. Each has a simple counter: verify routing actually distributes after you set a pool up, and treat filtering as a signal to fix authentication and lists, never as a reason to add IPs.

A worked multi-stream setup

Putting routing, separation and warm-up together, a realistic configuration looks like this — a dedicated transactional IP, a warm marketing pool, and a new IP held cold while it ramps:

<virtual-mta-pool pool-transactional>
    virtual-mta vmta-tx-1
</virtual-mta-pool>

<virtual-mta-pool pool-marketing>
    virtual-mta vmta-mkt-1
    virtual-mta vmta-mkt-2
    virtual-mta vmta-mkt-new      # cold, capped while warming
</virtual-mta-pool>

<source 10.0.0.0/24>
    default-virtual-mta pool-marketing   # safe default
</source>

Marketing mail from the app subnet defaults to pool-marketing and rotates across its IPs; the cold new IP carries only its capped share until warm. Transactional mail sets X-Virtual-MTA: pool-transactional per message to take the protected, dedicated IP instead. Add the matching subdomains and reverse DNS, and the two streams are isolated at both the IP and domain layers — a heavy promotional send simply cannot reach the IP your receipts go out on.

What a pool can’t do

A pool distributes reputation; it doesn’t manufacture it. Spreading mail across ten IPs doesn’t make a bad list deliver — it just gives you ten IPs with mediocre reputation instead of one, since the same poor engagement and complaint signals attach to whichever address sent each message. The inbox is still decided by authentication, list quality and how recipients react, exactly as it is on a single IP.

So treat pools as the distribution layer on top of a healthy sending program, never as a substitute for one. Get the fundamentals right — authentication, clean opt-in lists, content people want — and a pool then does its real job: letting that good mail scale across several IPs without overloading any one. Skip the fundamentals and a pool changes nothing except how many IPs you have to rehabilitate later. The reputation is the asset; the pool is just how you spread it cleanly.

Pools and consistency

A subtlety that interacts directly with pool sizing: IP reputation rewards consistency, and it decays. Mailbox providers weight recent sending heavily — reputation is effectively kept on a rolling window of roughly a month — so an IP that goes quiet for weeks is close to cold again when it resumes. Spread your volume across too many IPs and each one sends so sporadically that none stays reliably warm; the pool looks busy in aggregate while every individual address is starving.

This is the reputational case for keeping pools lean. Each IP in the pool needs a steady, sufficient flow to hold its standing, which means the pool should be sized so that every member stays consistently active at your real volume — not so large that mail trickles to each. If your sending is seasonal or uneven, a smaller pool that each IP can keep warm through the quiet periods beats a large one that goes cold between peaks. Consistency per IP, not raw IP count, is what builds the reputation a pool is meant to spread.

The bottom line

IP pools group several clean vMTAs so PowerMTA can spread mail across them in round-robin, distributing volume and reputation instead of concentrating both on one IP. You build a pool from per-IP vMTAs, route each stream to it via the X-Virtual-MTA header or a source default, keep transactional and marketing on separate pools and subdomains, warm every new IP before it shares load, and size the pool to real sustained volume.

Monitor each IP and rotate a bad one out without dropping the stream; layer pools with vMTAs and domain policy rather than overloading any one of them; and remember that rotation is reputation hygiene for wanted mail, never a way to evade filters — providers correlate across IPs and evasion burns them all. KumoMTA does the same with egress pools. If you’d rather not design, warm and police pools by hand, our managed deliverability service builds and tunes them, and the Auto PMTA Configurator maps clean IPs into separated, warmed pools at deploy, with the routing, cold caps and reverse DNS already in agreement — for legitimate, opt-in sending. Used that way, a pool is one of the most useful tools PowerMTA gives you; the only way to turn it into a liability is to reach for it as a shortcut around a sending problem it was never built to solve, in which case the extra IPs just multiply the cleanup rather than the deliverability, leaving you with more addresses to rehabilitate and no more mail in the inbox than you started with.