Infrastructure · Pro & Business tiers
Every dedicated IP in Mumara ONE belongs to you alone. Your sending reputation isn't pooled with strangers, your throughput isn't bottlenecked by noisy neighbours, and you decide which IPs route which traffic via Pools and Bridges. Real-time per-IP stats track every send.
View IPs
assigned to your account
Why dedicated IPs matter
Shared IP pools mix your reputation with every other sender on the platform. Dedicated IPs flip that around — your IP, your reputation, your control. Available on Mumara ONE Pro and Business tiers.
Shared vs dedicated
Most senders start on shared IPs and that's perfectly reasonable. The signal that it's time to upgrade isn't volume in absolute terms — it's the moment when your sending starts to differ enough from the pool average that you become an outlier.
Shared IPs work well when your sending pattern resembles the typical sender on the pool. You benefit from the pool's collective warm-up and reputation, you don't have to manage anything, and the platform handles routing for you. Mumara ONE Essential and Pro entry-tier customers run this way by default.
Dedicated IPs become the right answer when one of four things is true. (1) Your volume is high enough that your individual reputation drives outcomes more than the pool's. (2) Your list quality is materially better than the average sender on the pool, so being averaged in is hurting you. (3) Your list quality is materially worse and you don't want to drag the pool down — better to isolate the damage on your own IPs. (4) You need per-IP routing for compliance or segmentation reasons (e.g. transactional must not share IPs with promotional).
Pro and Business tiers in Mumara ONE include the ability to buy dedicated IPs. Each IP goes into a Pool you create, the Bridge connected to that Pool routes the matching traffic, and Mumara monitors the IP's health continuously. You see the same per-IP stats Mumara sees. No hidden numbers.
The three pillars
The Dedicated IP surface in Mumara ONE has three working parts. Each one exists because dedicated IPs without it would be incomplete — you need ownership, you need the routing layer, and you need the visibility.
Each dedicated IP is leased to your account exclusively. The status field reads 'dedicated' in the platform's database — distinct from shared-pool IPs. No other customer routes through this IP. Reputation that builds on the IP is yours; problems that develop are yours to fix. Your IP, your boundary.
Every IP belongs to one Pool at a time. A Pool (also called an MTA in the platform's terminology) is a named group of IPs that share routing logic — your promotional Pool might have 3 IPs in rotation, your transactional Pool might have 2 different IPs. Reassign IPs between Pools any time; the change queues and applies asynchronously.
Per-IP stats show Total Sent, Total Delivered, Total Bounced, and Total Complaints. A health indicator and DNS-confirmation badge sit next to each IP in the View IPs surface. When something looks off, you know exactly which IP — not 'somewhere on the account'.
The IP lifecycle
Buying a dedicated IP in Mumara ONE follows a fixed path. The ordering step goes through a ticket so the team can review and provision; everything after that is in your hands.
Submit an IP request from Setup → Dedicated IPs → Order IPs. Pick how many you need. The request opens a ticket for the operations team to review and allocate.
Once allocated, each IP needs DNS records validated. The DNS Status column reads CONFIRMED once Mumara verifies the records are in place. Sending only starts after confirmation.
New IPs land in a default Pool. Move them to the Pool that matches the traffic — promotional, transactional, nurture, or anything custom — via the Assign Pool action.
Bridges (SMTP / API endpoints) connect to Pools. Once your Pool has IPs and a Bridge, broadcasts and transactional API calls route through that Bridge and out the Pool's IPs.
Per-IP stats update in real time. Total Sent, Delivered, Bounced, Complaints. Health score and DNS status both visible in the list view. Use the data to spot reputation drift before ISPs do.
Per-IP stats
Click the stats icon next to any IP and Mumara shows the numbers that matter: total sent, total delivered, total bounced, total complaints. Real-time. Per IP. No need to cross-reference logs.
Want the same view aggregated across an entire Pool? Pools carry the same stats panel at the Pool level. Want delivery status streamed to your endpoint as it happens? See Realtime Delivery Status.
Sending stats of 203.0.113.10
sending statistics details of 203.0.113.10 smtp.
Delivery rate 97.0% · bounce rate 2.9% · complaint rate 0.0001%
First-IP setup
The path every dedicated IP takes from order to live sending. Most of it happens in your dashboard; the first step routes through the operations team for provisioning approval.
Step 1
Setup → Dedicated IPs → Order IPs. Choose how many you need. The form opens a ticket with the operations team — they review the request, your sending profile, and your tier eligibility, then allocate the IPs.
Step 2
Newly allocated IPs need DNS records validated — forward DNS, reverse DNS (rDNS / PTR), and your sending-domain authentication. Mumara checks all three. The DNS Status column flips to CONFIRMED when validation passes.
Step 3
By default new IPs land in a starter Pool. Reassign via the Assign Pool action to whichever Pool matches the traffic — promotional, transactional, drip, custom. Reassignments queue and apply asynchronously.
Step 4
Bridges live on top of Pools. Each Bridge exposes SMTP credentials or REST API endpoint that route through the Pool's IPs. Marketing broadcasts and transactional API calls send via the Bridge — they don't pick individual IPs.
Step 5
Start sending. Per-IP stats (Sent / Delivered / Bounced / Complaints) update in real time. Health scores and DNS status sit next to each IP in View IPs. Watch for reputation drift; rotate IPs between Pools if needed.
The cost of sharing
Shared IPs work right up until they don't. The failure modes are well-understood — most senders just don't see them until their open rate quietly drops 8 percentage points.
Your list quality is fine but the pool has one sender with a bad week. Their complaints get attributed to the shared IP, and your inbox placement quietly suffers. Dedicated IPs eliminate the failure mode entirely — your reputation is yours alone.
Most ISPs treat transactional and marketing email with different filtering. Sharing an IP between password resets and Black Friday promos means the marketing volume affects the deliverability of the transactional. Pools + dedicated IPs let you split them cleanly.
Bounce rate spikes — but you're on shared IPs, so you can't tell if it's you or a pool-mate. Dedicated IPs give you Total Sent / Delivered / Bounced / Complaints per IP. The diagnostic data is right where the problem is.
Some ISPs (especially enterprise mail filters) check reverse DNS on the connecting IP. A shared IP returns a generic Mumara-style hostname; a dedicated IP can return your brand's hostname. Higher-trust connection-level checks pass more easily.
“We moved our transactional email onto two dedicated IPs in a separate Pool. Marketing stayed on its own Pool with two IPs. Deliverability on the transactional side jumped 4 percentage points within a month — the marketing volume was dragging it down. We didn't know until we separated them.”
Verified review
Mumara ONE customer
Common questions
Pro and Business tiers in Mumara ONE include dedicated IPs. The Essential tier sends through shared infrastructure only. To add dedicated IPs, your subscription needs to be on Pro or Business — the upgrade is available any time from your account billing page.
Ordering goes through a ticket so the operations team can review the request and allocate. Typical turnaround is hours, not days, but it's not instant — the team checks your sending profile, current IP count against your tier limit, and any compliance requirements before provisioning. You're notified when the IP is allocated and DNS is being set up.
A Pool (the platform also calls these MTAs in some places) is a named group of IPs that share routing logic. Every dedicated IP belongs to exactly one Pool at a time. Pools exist because Bridges — the SMTP and API endpoints your apps actually connect to — route via Pools, not via individual IPs. Putting an IP in a Pool is how you make it usable. See the [Pools deep-dive](/one/features/pools/).
Yes. From View IPs, use the Assign Pool action and pick the destination Pool. The change queues — IP-assignment changes are async to avoid disrupting in-flight sends. The platform processes the move and updates the IP's Pool membership when safe. Useful when you reorganise traffic between transactional, promotional, and nurture Pools.
Each dedicated IP carries a health score visible next to it in View IPs. The score combines DNS validation status, bounce-rate trends, complaint signals, and blocklist checks into one number. Lower scores mean Mumara is detecting reputation pressure on the IP — investigate before continuing high-volume sends. The full breakdown lives in the [Reputation Monitoring](/one/features/reputation-monitoring/) surface.
Yes. The View IPs row action menu includes an Update rDNS Record option. Submit your desired hostname (typically a subdomain you control, e.g. mail.acme.com), and Mumara updates the PTR record on the IP. The hostname's forward DNS must match the IP — Mumara validates this before applying. Custom rDNS helps with high-trust connection-level deliverability checks.
Yes. A brand-new IP has no sending history; ramping up volume gradually over 2-4 weeks lets ISPs build a reputation signal for it. Standard practice: start at a low daily volume (1-2K/day to your most engaged contacts), double every 2-3 days, monitor bounces and complaints, and pull back if either spikes. Mumara's per-IP stats give you the data to watch this in real time. Talk to support if you want help planning a warm-up schedule.
Four headline numbers in the Sending Stats panel: Total Sent, Total Delivered, Total Bounced, Total Complaints. From those you derive delivery rate, bounce rate, and complaint rate. The same data is also available at the Pool level (aggregated across IPs in the Pool) and at the account level in [Reporting & Analytics](/one/features/reporting-and-analytics/).
Each plan tier has a per-account IP limit — set via your subscription package. Pro and Business tiers carry default limits with the option to request more via the ordering flow. The operations team approves additional IPs based on your sending volume; if you're already saturating existing IPs, more usually get approved. The Plan section of your dashboard shows current usage against limit.
Yes. The Zone column on each IP shows which sending zone it's in — MTA4 (the platform default), US-1, and others depending on your deployment region. Zone selection matters for data-residency requirements and for matching IP location to your recipient base. If you need IPs in a specific region not shown in your account, request it via the IP order flow.
Related
Group dedicated IPs into named Pools. Every IP must belong to a Pool — Pools are how routing logic works. Multi-IP rotation inside each Pool.
Read moreSMTP and REST API endpoints that sit on top of Pools. Your apps connect via Bridges; Bridges route via Pools; Pools route via dedicated IPs.
Read moreDKIM, SPF, and DMARC authentication on the domains you send from. Dedicated IPs work hand-in-hand with authenticated sending domains for inbox placement.
Read moreLive per-IP and per-domain reputation tracking against major blacklists and reputation feeds. Auto-rules can throttle or rotate when reputation drops.
Read moreReal-time DSN delivery events — received, queued, delivered, bounced — each carrying the sending node IP. Per-IP delivery attribution included.
Read moreReal-time bounce + complaint handling. Hard bounces auto-suppress; complaints feed the suppression layer. Per-IP bounce attribution.
Read moreMumara ONE · Dedicated IPs
Dedicated IPs ship with Mumara ONE Pro and Business tiers. Order via your dashboard, assign to a Pool, connect a Bridge, send. Per-IP stats, DNS validation, customer rDNS, and reputation monitoring all included.
