Infrastructure · Pro & Business tiers
A Pool is a named group of dedicated IPs with shared routing logic. Put promotional traffic on one Pool, transactional on another, nurture drips on a third — and your reputation stays cleanly partitioned. Bridges sit on top to expose SMTP and API endpoints per Pool.
Dedicated Pools
named groups of IPs
What a Pool IS
A Pool isn't a folder or a tag — it's an actual routing decision. The Pool an IP belongs to determines how outgoing email gets tagged at the MTA, which Bridge exposes it to your applications, and which campaigns end up flowing through it.
Each Pool is a named container for one or more dedicated IPs. Give it a label that means something to your team — 'acme-promotional', 'acme-transactional', 'nurture' — and the platform tracks every IP in the Pool as a logical unit. One IP, one Pool, always.
Bridges (SMTP / API endpoints) bind to Pools. Your marketing app connects to the promotional Bridge → traffic flows through promotional Pool's IPs. Your application code calls the transactional Bridge → traffic flows through transactional Pool's IPs. No mixing.
Multiple IPs per Pool? Mumara distributes sends across them automatically. The rotation spreads volume — protecting individual IP reputation — while still letting you treat the Pool as a single logical destination. Add more IPs to grow capacity; remove IPs to shrink.
Two reasons most operators split traffic
The two most common Pool patterns we see in production. Both come from the same operational reality: marketing volume affects deliverability differently than transactional volume, and ISPs treat them differently too.
High volume · variable list quality
Big sends, audience engagement varies, list hygiene depends on the cohort. The IP on this Pool absorbs the natural volatility of marketing campaigns — open-rate dips, occasional complaint spikes, list-churn bounce events. You don't want the password-reset email to inherit that volatility.
Low volume · high-trust delivery
Password resets, order confirmations, magic-link logins. Smaller volume, near-zero unwanted/unsolicited, must hit inboxes within seconds. ISPs filter transactional differently than marketing — separate Pool keeps the reputation high and the inbox placement near-perfect.
Pool, MTA, virtual-MTA — the same thing?
The platform uses 'Pool' on most customer-facing surfaces, 'MTA' in some places (because each Pool maps to an MTA backend that actually carries the email), and 'virtual-MTA' in the email headers. Same underlying object, different naming for different contexts.
When you create a Pool in the dashboard, you give it a friendly label (e.g., 'acme-promotional'). The platform also generates an internal pool name following a fixed pattern — your tag, user ID, server ID, the literal word 'pool', and the SMTP ID — joined by hyphens. The friendly label is what you see; the internal name is what the routing layer uses.
Behind the scenes, each Pool is backed by an MTA server (the mail-transport-agent that actually carries the email out). That's why some places of the UI call Pools 'MTAs' or 'Sending MTAs' — they're the customer-facing representation of the MTA backend. You'll see the column 'Type · Dedicated' next to each Pool, signaling it's your dedicated MTA, not a shared one.
On outgoing emails, the platform adds an `x-virtual-mta` header containing the Pool's internal name. ISPs and downstream analytics use this header to identify the sending MTA. Two more headers ride along — `x-feedtype` (the type of mail, e.g., newsletter / transactional) and `x-zone` (the geographic region of the MTA backend). All three are auto-injected; you don't write them by hand, but they're visible if you inspect the raw email source.
What's inside a Pool
A Pool isn't just an IP container. It's the unit that ties together the dedicated IPs your sends route through, the Bridges that expose those IPs to your apps, and the metadata that gets injected into every outgoing email for downstream attribution.
Every Pool contains at least one IP — usually more. Multi-IP Pools rotate sends across the IPs to spread reputation load. Add IPs by ordering more and assigning them to this Pool; remove by reassigning to a different Pool.
Bridges expose the Pool as SMTP credentials and a REST API endpoint. Your downstream apps connect via the Bridge. One Pool can host multiple Bridges (e.g., separate Bridge per app), each with its own credentials but routing through the same Pool's IPs.
Every email routed through the Pool carries auto-injected headers: x-virtual-mta, x-feedtype, x-zone, x-serverid. ISPs and downstream analytics read these for attribution.
Per-Pool stats
Click the Sending Stats icon on any Pool row and Mumara shows the three aggregate numbers across every IP in that Pool: Total Sent, Total Delivered, Total Bounced. Drill into a specific IP for the per-IP view (with complaints).
Sending stats of acme-promotional pool
sending statistics details of acme-promotional smtp.
Delivery rate 97.0% · across 3 IPs in this Pool
Pool lifecycle
Creating and using a Pool is a five-step path. Most steps are in your dashboard; the routing change between assigning an IP and the IP actually carrying traffic happens asynchronously to avoid disrupting in-flight sends.
Step 1
Setup → Dedicated Pools → Add a Pool. Pick a label that means something to your team ('acme-promotional', 'acme-transactional'). Choose the MTA server (which determines the Zone). Save. The Pool exists but has no IPs yet.
Step 2
From Dedicated IPs, use the Assign Pool action on each IP. Multi-IP Pools rotate sends automatically across the IPs. Assignment is queued (async) — the platform updates routing tables and confirms when ready.
Step 3
Bridges expose the Pool as SMTP / API. Setup → Bridges → Create. Pick the Pool. The Bridge issues credentials your downstream apps use to connect. One Pool can host multiple Bridges.
Step 4
Apps send via the Bridge credentials. The platform routes through the Pool's IPs (rotating across multi-IP Pools) and the destination MTA delivers. Auto-injected headers (x-virtual-mta, x-feedtype, x-zone, x-serverid) tag every email.
Step 5
Per-Pool stats panel shows Total Sent / Delivered / Bounced in real time. Per-IP drill-in for deeper investigation. Reassign IPs between Pools any time — useful when traffic patterns change or when isolating a misbehaving IP.
The Pool, in numbers
Pools work because email senders have heterogeneous traffic — marketing isn't transactional isn't nurture isn't password reset. Pool segmentation lets the platform reflect that reality at the infrastructure layer.
What goes wrong without Pool segmentation
A single dedicated IP without a Pool, or all traffic forced through one mega-Pool, surfaces the same issues every time. Pool segmentation isn't optional once you're past a certain volume — it's how senders avoid sending themselves into a deliverability hole.
When marketing and transactional share IPs, the marketing volume drives the ISP's reputation signal for the shared IP. A bad marketing week (open-rate dip, complaint spike) hurts the transactional email's inbox placement. Splitting into two Pools isolates the failure mode completely.
Account-wide bounce rate ticks up — but you're running everything through one Pool, so you don't know if it's the morning newsletter or the order-confirmation traffic. Pool segmentation gives you Sent / Delivered / Bounced rollups PER Pool. Diagnosis becomes specific instead of vague.
EU customers need EU-region sending IPs for data-residency reasons. Multiple ESP backends for redundancy. Different brands under one parent account, each wanting reputation isolation. Pool segmentation maps directly onto each of these — one Pool per requirement.
If your transactional is one IP and that IP gets a temporary reputation hit, your transactional inbox placement tanks. Multi-IP Pools rotate sends across IPs — the impact of one IP's bad day gets diluted across the others. No single point of failure at the IP layer.
“We split into three Pools — transactional, promotional, drip. Took an afternoon to set up and reassign IPs. Inboxing on the transactional side jumped within two weeks. The marketing Pool's bounce rate became visible and actionable — we caught a stale list segment we hadn't realised was hurting us. Pools made the data legible.”
Verified review
Mumara ONE customer
Common questions
They're the same object, named differently in different contexts. In the customer-facing UI (Setup → Dedicated Pools) it's called a Pool. The platform also calls Pools 'MTAs' or 'Sending MTAs' in some places because each Pool maps to an MTA server backend that carries the email. In outgoing email headers, the Pool's identifier shows up as `x-virtual-mta`. Pick whichever name fits the context you're talking about — the underlying object is the same.
When you order your first dedicated IP, Mumara creates a default Pool for it. You can rename that Pool, create new Pools (Setup → Dedicated Pools → Add a Pool), and reassign IPs between them. One Pool is always flagged as the default — that's where newly provisioned IPs land if you don't specify another Pool.
Yes. From Dedicated IPs, use the Assign Pool action and pick the target Pool. The change is queued (the platform updates routing asynchronously to avoid disrupting in-flight sends), and the IP starts routing through the new Pool once the change is applied. No interruption to other IPs in either Pool.
No hard upper limit. Create as many as your traffic patterns justify. Most operators settle on three to five — transactional, promotional, drip, recovery, plus maybe one or two per-brand or per-region Pools. There's no benefit to creating Pools you don't actually need; the value is in the segmentation, not in the Pool count.
Four auto-injected headers: `x-virtual-mta` (the Pool's internal name), `x-feedtype` (the type of mail — newsletter, transactional, etc.), `x-zone` (the geographic region of the MTA backend), and `x-serverid` (the specific MTA server). ISPs and downstream analytics can read these for attribution. You don't write them; the platform handles injection at send time.
Three aggregate numbers: Total Sent, Total Delivered, Total Bounced — summed across every IP in the Pool. (Complaints are tracked per-IP rather than per-Pool, since FBL data typically arrives with IP attribution.) Click the Sending Stats icon on any Pool row to see the rollup. Drill into any IP in the Pool for the per-IP breakdown including complaints.
Yes. Each Pool is bound to one MTA server at creation, and the MTA server determines the Zone (MTA4, US-1, etc.). To run sends from multiple Zones — say, EU and US — create separate Pools, each on the appropriate MTA backend. Some operators use this for data-residency compliance, others for geo-routing optimisation.
Yes. One Pool can host many Bridges. Common pattern: separate Bridges per app (`api-mobile-bridge`, `api-web-bridge`) all routing through the same `transactional-pool`. Each Bridge has its own credentials so you can revoke one without affecting the others, but they share the underlying IP rotation.
Dedicated Pools require Pro or Business tier in Mumara ONE — same gating as Dedicated IPs. The Essential tier sends through shared infrastructure with no Pool configuration. Upgrading unlocks Pool creation and IP assignment via your account billing page.
You can't delete a Pool while IPs are still assigned to it. Reassign every IP to a different Pool first, then delete. This is intentional — deleting a Pool with live IPs would orphan the routing layer. The platform's deletion flow prompts you to reassign before deleting.
Related
The IPs that live inside Pools. Every Pool needs at least one IP; every IP belongs to one Pool. Order, assign, monitor — that's the lifecycle.
Read moreSMTP and REST API endpoints created on top of Pools. Your apps connect via Bridges; Bridges route via Pools; Pools rotate IPs. The send-time pipeline.
Read morePer-IP and per-Pool reputation tracked against major blacklists and reputation feeds. Auto-rules can pause Pools or rotate IPs when reputation drops.
Read moreDKIM, SPF, DMARC authentication per domain. Pool routing + authenticated domains together give ISPs the trust signals they actually filter on.
Read morePool-level aggregates roll into the broader reporting surface. Per-Pool deliverability rates, complaint rates, conversion attribution.
Read moreReal-time bounce + complaint events attributed to specific IPs and Pools. Hard bounces auto-suppress; trends visible per Pool.
Read moreMumara ONE · IP Pools
IP Pools ship with Mumara ONE Pro and Business tiers. Create as many as your traffic patterns justify, assign IPs to each, expose them via Bridges. Per-Pool stats, multi-IP rotation, auto-injected attribution headers — all part of the deal.
