Managed PowerMTA — license, hardware and operations in one bill
Commercial PowerMTA, single-tenant, with the license, the dedicated hardware, the configuration and the day-to-day operations all rolled into one monthly invoice. Virtual MTAs for stream isolation, dedicated IP pools with reverse DNS configured, per-domain throttling that actually does what the docs say. The Stockholm team has been running PowerMTA-class infrastructure since the year PowerMTA 2.0 shipped, which means we've seen enough configurations work and enough configurations break to know what good looks like.
PowerMTA enters the conversation when a relay layer has stopped doing the job. The boundary is roughly 100,000 messages an hour sustained — past that point the simpler MTAs are choking, the per-domain throttling defaults are too coarse, or the team needs explicit stream isolation that just isn't there in a managed relay. Multi-tenant platforms wanting per-customer reputation isolation hit this fast. So do ESPs separating transactional from marketing onto separate IP pools, or any operation running warmup pools alongside production pools. People searching for managed PowerMTA, PowerMTA hosting, or dedicated PowerMTA server are usually past the relay-vs-API decision and into infrastructure depth.
This service exists because the alternatives to a managed PowerMTA are all uncomfortable. Option one: buy the $8,000-per-year production license from Bird, source the hardware, configure the platform from a blank pmta.conf, build your own monitoring, handle your own incident response, and do all that with an MTA that has a steep learning curve and a vendor whose feature investment has cooled since the SparkPost-to-Bird transition. Option two: pay someone else to do that. The managed path replaces the whole stack with one monthly invoice — license included, hardware included, configuration done, monitoring running, on-call covered — from a team that's been running this class of infrastructure since 2003.
What's in every plan
The PowerMTA license
Production license rolled into the monthly bill. No separate Bird quote to chase, no per-server upcharge, no renewal-time surprise increases. License is current, supported, and updated as Bird releases security and bug fixes.
Dedicated hardware
Xeon-class CPU, NVMe storage, 32GB or more of ECC RAM depending on plan. Single tenant. The server is sized to actually hold the documented throughput under healthy reputation, not to look good in a feature comparison.
Dedicated IPs with rDNS
Four to sixteen IPs per plan. PTR records aligned to your sending domain — the kind of small thing nobody thinks about until a receiver flags it. Warmup guidance for the first 21 days, included.
Virtual MTAs (vMTAs)
Pre-configured queue isolation: 5 on Standard, 15 on Pro, 50 on Enterprise. This is the primitive for separating transactional from marketing, or holding per-customer reputation in a multi-tenant platform. Without vMTAs, all your sending shares one fate.
Per-domain throttling
Outbound rate shaping that matches the published guidelines for Gmail, Outlook, Yahoo, AOL and the other major receivers. Bursts get smoothed before they trigger receiver-side throttling; deferrals are managed automatically rather than dumped on you to investigate.
FBL ingestion + smart bounce
AOL, Yahoo and Hotmail feedback loops registered against your IPs out of the box. PowerMTA's bounce categoriser handles the classification work — hard, soft, spam-block, policy reject — and feeds suppression lists automatically.
Full delivery logs
30 days default log retention (longer on request). Per-message attempt history, SMTP response codes, deferral reasons, queue state. Exportable for analysis.
Monitoring + alerting
Per-vMTA queue depth, per-IP placement signals, complaint rate alarms, blocklist watch on Spamhaus and other major lists. Email and webhook alerts.
Three plans plus a Custom quote
The price reflects the actual bundle — license, hardware, configuration, ongoing operations. Each tier documents the sustained throughput envelope the server is sized for, the dedicated IP count, and the vMTA count.
One thing about the throughput numbers. The published figures describe what the hardware and PowerMTA configuration can hold up sustained — warmed IPs, healthy sender reputation, a validated list, normal receiver-side acceptance. The actual deliverable volume depends on a different set of variables: list quality and engagement, where you are in the IP warmup curve, sending domain reputation, content profile, and what Gmail or Outlook or Yahoo decides to throttle on any given day. A fresh server with cold IPs and an unvalidated list will deliver a fraction of the published ceiling during the first weeks. The same server with fully warmed IPs and a clean list approaches it. The number describes what the box can do, not what any given campaign will achieve on day one.
Annual prepayment qualifies for a 10% discount across all three published plans. Custom plans cover any combination of higher throughput, larger IP allocations, multi-server clusters, MTA selection (KumoMTA hosting available on Custom for teams preferring open source), and specialized configurations. Onboarding for a new managed PowerMTA environment typically takes three to five business days from order confirmation to first message delivered: time required is mostly for IP allocation, reverse DNS provisioning at the upstream network, DKIM key publication, and your existing pmta.conf migration if applicable.
Why managed PowerMTA at €899 makes more sense than self-hosting
The total cost of self-hosted PowerMTA breaks down roughly as follows: PowerMTA production license at $8,000 per year, which is $666 per month amortized; a dedicated server capable of running PowerMTA cleanly at $200 to $400 per month depending on hardware and provider; a separate development/test license that Bird charges for separately ($2,000+ per year); and the engineering time of an operator who knows PowerMTA — usually four to eight hours per month for monitoring, tuning and incident response, which at conservative agency rates is $400 to $1,600 per month. Add it up and self-hosted PowerMTA realistically costs $1,300 to $2,800 per month before you've sent the first message. The Authorize Hosting Standard plan at €899 includes all of that as a single bundle, with the additional advantage of an operator who has been running PowerMTA-class infrastructure for two decades. Self-hosting only wins economically when the sending program is large enough to amortize a full-time email infrastructure engineer, which is well into Enterprise territory.
How this compares to Bird, KumoMTA and the alternatives
The PowerMTA-class managed hosting market has a few legitimate options and a much longer tail of operators with thin reputations, unstable pricing, and sometimes unlicensed installations. The honest comparison looks like this:
Managed PowerMTA-class options compared, April 2026
Mixed; many short-lived operators with negative reviews
Self-hosting on AWS/DigitalOcean
$8,000+/year license
Cloud server you operate
You
Whatever your team brings
The shape of that table reflects a structural choice on each side. Bird sells the license but expects you to operate it. KumoMTA gives you the open-source platform but expects you to operate it. MailerQ is another commercial option for teams that prefer its management console — fine product, smaller community. The thin tail of "PowerMTA hosting" providers is where most of the bad reviews live: operators of unclear provenance, occasional unlicensed installations, the kind of operational continuity that's about what you'd expect from that profile. Our position is the one you'd expect from a serious EU-based managed offering — full license, dedicated hardware, real operations, 23 years operating since 2003. Not the cheapest option in the table, and not trying to be.
Where managed PowerMTA sits in the architecture
Managed PowerMTA architecture — vMTAs, IP pools, recipient deliveryEach vMTA inside PowerMTA is its own queue, its own IPs, its own throttling rules, its own bounce handling. A complaint storm in the marketing vMTA does not affect transactional reputation. A new IP in the warmup pool grows without contaminating the production pools. Multi-tenant platforms can isolate per-customer reputation cleanly. This architecture is what justifies PowerMTA in the first place — and it's why the price tag sits noticeably higher than a single-pipe SMTP relay.
What a real PowerMTA config looks like
The configuration model is plain text files describing vMTAs, domain-level routing, throttling rules and DKIM signing. The example below is a minimal but realistic two-vMTA setup — separate IPs for transactional and marketing, per-receiver throttling tuned for Gmail and Yahoo, DKIM signing aligned to the sending domain. This is exactly the kind of config that comes pre-built on a managed plan, but seeing the actual syntax makes the architecture concrete in a way that bullet points don't.
On a managed plan, this configuration is built and tuned for your specific sending profile during onboarding. You don't have to learn the syntax to use the platform, but having the option to read and modify the config file directly is part of what distinguishes managed PowerMTA from a wrapped abstraction.
The shapes that fit this
ESPs and senders at 1M+ messages per monthWhere receiver throttling, vMTA isolation and per-domain rate shaping become operational requirements rather than nice-to-haves.
Multi-stream architecturesTransactional and marketing on separate vMTAs and IP pools; product notifications never share fate with promotional sends.
Multi-tenant SaaS sendingOne vMTA per customer, isolated reputation per tenant. Critical for white-label platforms where one customer's behaviour must not damage the next customer's deliverability.
Agencies running mail for clientsDedicated vMTA per client account with independent IP allocation. Cleaner than commingling client traffic on a generic relay.
High-stakes transactional at scaleBanking, fintech, healthcare alerts where receiver-level control over throttling and routing affects compliance posture.
Newsletter operators with serious volumeSubstack-class operators, large independent newsletters, media companies. PowerMTA's queue management is built for this profile.
Outbound marketing platformsBuilt on a sending-engine layer, not on shared SaaS providers. PowerMTA is what gets bundled underneath.
Migrations from self-hosted PowerMTAIn-house teams that want out of the operational burden but want to keep the platform they already understand. Bring your pmta.conf, we adapt it.
When this beats Relay, API, or Dedicated Servers — and when it doesn't
SMTP Relay is the better answer for most sending up to about 50,000 messages a day, especially when the application already speaks SMTP and per-stream isolation isn't a hard requirement. Email API is the better answer when sending logic should live deep in product code and developer ergonomics matter more than throughput ceilings. Dedicated Email Servers are the better answer when you want bare metal without commercial MTA licensing — Postfix, Exim, or KumoMTA on the open-source side. PowerMTA Servers earn their place when you specifically need PowerMTA: the commercial MTA built around vMTA isolation, granular per-domain throttling, the smart bounce categoriser, and the operational depth that comes from two decades of deployment in the largest sending environments. Four services for four different operational questions. They're not stacked vertically by quality; they answer different problems.
Technical specifications, briefly
PowerMTA version
Currently shipped on the latest stable PowerMTA release supported by Bird, with security and bug-fix updates applied within standard maintenance windows.
AlmaLinux 9 by default; Rocky Linux, Debian and Ubuntu LTS available on Custom plan. PowerMTA runs on the operating system; you don't manage the OS unless you want to.
Submission interfaces
SMTP listener (port 25 internal, 587 external), HTTP submission API for application clients that prefer HTTP, both behind TLS.
vMTA isolation
Each vMTA has its own SMTP source IP set, queue management, throttling configuration and bounce processing rules. Per-vMTA SignalDB instances available on Pro and Enterprise.
DKIM signing
Per-domain DKIM keys with selector rotation. Multiple selectors per domain supported. RSA 2048-bit standard, Ed25519 available on request.
Logging
Full PowerMTA accounting files (acct.csv) with delivery, bounce, defer, FBL, complaint events. 30-day default retention; longer on request. Exportable.
Monitoring
Per-vMTA queue depth, per-IP placement signals, complaint rate, bounce ratio, blocklist watch. Alerts via email or webhook to your endpoint.
Migrating in from self-hosted PowerMTA or another managed provider
Most teams arriving at managed PowerMTA are migrating from one of three previous setups: self-hosted PowerMTA where the operational burden has stopped being fun, another managed provider whose service quality or pricing took a turn, or PowerMTA-class workloads currently running on something less suitable — generic Postfix usually — where the lack of vMTA isolation has started causing visible problems. The pattern across all three migrations is consistent.
From self-hosted, bring your existing pmta.conf and DKIM private keys. We adapt the vMTA naming, the source IP allocation, the routing logic to the new environment, and we preserve everything that doesn't need to change. The dedicated IPs themselves are new — that means 14-to-21 days of warmup before they carry full production volume — but the configuration continuity removes the biggest source of migration risk by far. Parallel sending during warmup is the right shape: keep the existing environment running while the new IPs build reputation, then cut over when the new pools are stable.
From another managed provider, the same pattern applies. We accept your incoming pmta.conf, adapt it cleanly, and handle the operational handoff with the previous operator if you'd like us to. From generic Postfix or Exim where the team has decided PowerMTA's vMTA model is now warranted, onboarding includes designing the vMTA architecture from scratch against your actual sending profile — typically two or three working sessions to get the routing right before any traffic moves.
Common questions about Managed PowerMTA
FAQ
The questions that come up most often before someone signs
What is PowerMTA and why does it cost more than a regular SMTP server?
PowerMTA is a high-performance commercial Message Transfer Agent built for sending volumes that traditional SMTP servers struggle with — typically 50,000 to 500,000 messages per hour from a single server. The differentiators are virtual MTA isolation, per-domain throttling that matches receiver guidelines, smart bounce categorisation, FBL processing, and the kind of detailed delivery analytics you can actually act on. Bird (formerly SparkPost) sells the standalone production license starting at $8,000 per year. Our managed plans bundle the license, the dedicated hardware, the configuration and the ongoing operations starting at €899 per month — which compares pretty favourably once you've honestly accounted for what running PowerMTA yourself actually costs.
Why €899 per month instead of just buying a license?
The license alone starts at $8,000 per year for production, and that's only the production license — development and test environments need separate licenses on top. Then you need a dedicated server (typically $200 to $400 per month for hardware PowerMTA runs well on). Then you need an operator who actually knows the product — initial configuration, monitoring, vMTA design, IP warmup, FBL processing, incident response. €899 reflects the full bundle from a team that's been running PowerMTA-class infrastructure for two decades. Building the same thing yourself usually ends up costing more once you honestly count the engineering time and the on-call rotation.
What's the difference between PowerMTA and SMTP Relay?
Different shapes for different scales. SMTP Relay is a managed sending layer with dedicated IPs that fits transactional and operational workloads up to about 50,000 messages a day. PowerMTA Servers are a commercial high-performance MTA with explicit routing control, vMTA isolation between traffic streams, sophisticated queue management, and the operational depth that comes with running a real commercial MTA. The cross-over point is roughly 100,000 messages per hour sustained, or when multi-stream architecture (separating transactional from marketing, or per-customer reputation isolation in a multi-tenant platform) has become a requirement rather than a nice-to-have.
How does this compare to Bird's PowerMTA cloud or KumoMTA?
Bird (current owner of PowerMTA, formerly SparkPost, formerly MessageBird — acquired by MessageBird, now rebranded Bird) sells PowerMTA primarily as a self-managed license. Their hosted Signals product is analytics-focused rather than full operations. KumoMTA is an excellent open-source alternative released in 2024-2025, built by ex-PowerMTA engineers with Lua scripting and direct migration paths from PowerMTA — but you still need to run and operate it yourself. We're managed: we install, tune, monitor and operate the platform, with a Stockholm team that's been doing this for 23 years. The choice is really about whether you want to own the operational complexity or want it handled.
What are virtual MTAs (vMTAs) and why do they matter?
A vMTA is an independently configured sending pipeline inside PowerMTA — its own IP address, its own queue, its own throttling rules, its own bounce processing. They're how you isolate sending streams: one vMTA for transactional, one for marketing, one per customer in a multi-tenant architecture, separate ones for warming new IPs alongside production. Standard ships with 5; Pro with 15; Enterprise with 50; Custom is uncapped. Without vMTAs, all your sending shares one fate. With them, a complaint storm in one stream doesn't kill the reputation of the others — which is exactly the kind of insulation a serious sender starts needing as scale grows.
How many emails per hour can a PowerMTA server actually send?
The architecture is built for high throughput — well-configured deployments routinely move 50,000 to 500,000+ messages per hour from a single server, and there are public reports of 60 million messages per day from individual installations. But real-world rates depend much more heavily on receiver-side throttling at Gmail, Outlook, Yahoo and the others. The MTA is almost never the limiting factor in modern sending; it's the per-receiver delivery rates that healthy reputation actually allows. Plan throughput numbers reflect realistic sustained sending under good reputation, not the theoretical ceiling that benchmarks would show.
What does the Standard plan actually include?
The full PowerMTA license. A dedicated server (Xeon-class CPU, 32GB RAM minimum, NVMe storage). Four dedicated IPs with reverse DNS configured to your sending domain. Five vMTAs with isolated queue management. Automated bounce processing through PowerMTA's smart bounce categoriser. FBL ingestion from AOL, Yahoo and Hotmail. Per-domain throttling matching the published receiver guidelines. Full delivery logs with 30-day retention. Operational monitoring with alerts on queue health and reputation signals. Setup, initial configuration, and IP warmup guidance — the operational handover, included.
Can I bring my existing PowerMTA configuration?
Yes — and migrations from existing PowerMTA installations are common. Agencies switching providers, in-house teams handing operations off, companies modernising legacy setups. Bring your existing pmta.conf and we adapt it to the new environment, preserving the vMTA names, the routing logic, the DKIM keys, and any custom throttling rules that already work. The dedicated IPs themselves are new (warmup is required, no shortcut), but configuration continuity removes most of the migration risk by far.
Do you offer KumoMTA hosting as an alternative?
Yes — on the Custom plan. KumoMTA is a credible open-source alternative to PowerMTA, similar architecture, similar throughput characteristics, with Lua scripting in place of plain config files. The choice between them is mostly philosophical: PowerMTA gives you a mature ecosystem with commercial support and an established license model; KumoMTA gives you open-source transparency and no recurring license fee, but the support model is community-plus-paid-tier rather than vendor-warranted. We've shipped both. We have opinions about both. We're happy to walk through the trade-offs in a scoping call.
What about MailerQ or other commercial MTAs?
MailerQ is another commercial option from Copernica, with a strong management console — a fine product, smaller community than PowerMTA's. We focus on PowerMTA and KumoMTA because those are the two architectures most teams in our segment actually evaluate, and concentrating expertise on those two means faster incident response and deeper tuning than a multi-MTA shop typically delivers. There are real specialists for MailerQ; we're not them.
Is PowerMTA still being actively developed?
Yes, though the pace of major feature releases has clearly slowed since the Bird acquisition. The platform itself remains mature and battle-tested — Bird claims around 40% of global email traffic transits PowerMTA installations, and that scale doesn't disappear quickly. But we've seen reports of cost increases after the Bird transition and a feeling among some long-term users that core feature investment has cooled off. For teams that find that trajectory uncomfortable, KumoMTA on our Custom plan is the open-source alternative we'd recommend evaluating in parallel — it was built by ex-PowerMTA engineers specifically because of that trajectory.
Customer engagements
Three deployments where PowerMTA was the right call
Real engagements, names withheld. Each one shows PowerMTA solving a problem that a relay or shared-pool provider couldn't have — vMTA isolation, throughput, stream segregation. The numbers and the technical specifics are exactly what they were.
01
UK newsletter publisher — 8M sends per week with stream segregation
Independent newsletter network, London-based, around 35 newsletters under one roof
Context
Mixed audience reputations across the 35 properties were dragging the worst-performing newsletters' deliverability across the entire IP pool. Editorial leadership had a clear ask: each newsletter should stand or fall on its own reputation, not on whichever underperformer was sharing IPs with it that week.
Implementation
Managed PowerMTA Standard tier with one virtual MTA per newsletter property. Independent IP pools per vMTA, each with rDNS, distinct DKIM key, and isolated bounce/FBL routing. Volume modeling done with the operator before warming each pool.
Outcome
Top-quartile newsletters' Gmail open rates moved from 23% to 31% once they no longer shared reputation with weaker properties. Bottom-quartile newsletters' issues now isolated and remediated property-by-property without affecting the network.
Performance marketing operator headquartered in Amsterdam
Context
Sustained 100k messages per hour required for affiliate partner campaigns. Previous self-managed PowerMTA deployment took 9 months to stabilise and required two FTE engineers for ongoing tuning. Costs and operational drag became unsustainable.
Implementation
Migrated to Managed PowerMTA Pro tier. Operator team handled full configuration: VirtualMTA design, smart_source_routes, Gmail-specific throttling, Yahoo back-off curves, Microsoft batch sizing. Existing affiliate platform integrated via SMTP submission.
Outcome
Stabilised sending in week 3 instead of month 9. Internal engineering effort: zero ongoing. Total cost of ownership 60% below the prior self-managed setup once licence + hardware + engineer time was accounted for.
03
French publisher — daily editorial newsletter to a 2M-subscriber base
Major French-language news publisher headquartered in Paris
Context
Single morning send window of 06:00–07:30 CET delivered to 2 million subscribers. The previous infrastructure took 4+ hours to drain the queue, meaning a meaningful portion of subscribers received the morning newsletter at lunch — defeating the editorial product.
Implementation
Managed PowerMTA Pro with 12 IPs across two pools sized for the burst. Operator-tuned concurrency limits per receiving domain — aggressive for Microsoft, conservative for free providers in early weeks. Pre-flight rendering moved to a separate staging step to remove that latency from the send window.
Outcome
Queue drains in 38 minutes for the full 2M base. Morning delivery now consistently within editorial intent. Subscriber complaints about late delivery dropped to near zero.
04
German ESP — building a vertical sending platform on top
Specialised ESP for the German real-estate industry, based in Munich
Context
Founder was operating a small WhatsApp-style relay using SendGrid and growing fast enough that per-email costs dominated unit economics. Wanted a true platform play with branded IPs and customer-isolated reputations, not a SendGrid wrapper.
Implementation
Managed PowerMTA Pro with the operator providing API access for vMTA provisioning. New customer onboarding triggers provisioning of an isolated vMTA + IP allocation through a small management layer the customer's team built on top.
Outcome
Per-email cost dropped 75% versus pass-through SendGrid pricing. Founder rebuilt their pricing model around this and grew margin while reducing customer prices. Now operating with 60+ customers at the time of writing.
05
Spanish marketing agency — managing client sending across separate brands
Full-service marketing agency in Madrid, mid-tier client portfolio of around 25 brands
Context
The agency previously rebilled SendGrid, which was profitable but provided no defensible value. Clients increasingly asked questions about deliverability that the agency could not answer with authority because they did not own the infrastructure.
Implementation
Managed PowerMTA Standard with the operator handling configuration and the agency handling client-facing reporting. One vMTA per client brand. Custom dashboard integrating PowerMTA accounting data with the agency's client portal.
Outcome
The agency's deliverability practice transitioned from a pass-through cost to a defensible service line. Average revenue per client increased 22%. Three clients renewed at the next tier on the strength of the deliverability reporting alone.
All engagements anonymised at the customer's request. Industry descriptors, volumes, and technical details reflect actual deployments. Specific company identifiers have been withheld.
Related services
Related services worth comparing
PowerMTA decisions are rarely isolated. The most common next question is whether the business also needs dedicated infrastructure, stronger deliverability support or both.
Important when authentication, warmup, monitoring and reputation handling matter as much as the mail transfer layer itself.
Where to look next
Three places that usually answer the next question
PowerMTA buyers usually need to compare three things: whether advanced control is genuinely necessary at this scale, whether dedicated infrastructure is already required, and how much deliverability management should sit around the sending layer itself.
