Continuous managed operation of self-hosted PowerMTA infrastructure for teams that already hold a valid Bird/Port25 license but lack the in-house bandwidth to operate it 24x7. Daily covers virtual-mta concurrency calibration against current Gmail, Yahoo, Microsoft and Apple throttle policies, retry-interval ladder maintenance, accounting log shipping with integrity checks, IP pool design and rotation, bounce-pattern tuning for accurate 4XX versus 5XX classification, FBL processing pipeline, queue depth monitoring with alert thresholds calibrated to your specific traffic shape. Weekly bounce-pattern review against the last seven days of accounting data, retry-interval recalibration if ISP throttle policy has shifted, IP reputation review against Sender Score and Talos. Monthly SLA report with throughput, latency, deferral, and bounce-categorization accuracy benchmarked against your established baseline. EMP is independent of Bird. No licensing tier upsell pressure. No preferred-vendor recommendations. License relationship stays directly between your company and Bird. 16 years operating PowerMTA in production. From $1,890 per month single-node managed up to $9,890 per month enterprise multi-region cluster.
Managed service is not a black box. Every action taken on your PowerMTA infrastructure goes into a Git-backed runbook the client has read access to from day one. Every command applied has a documented rollback procedure. The client retains root SSH access to all nodes at all times — we do not operate exclusively through a vendor portal that hides what is happening. The four cadence cycles below cover what gets touched and when, with explicit deliverables for each cycle. The structure exists so that the relationship survives staff turnover on either side: if your VP Engineering changes or our primary engineer rotates off your account, the runbook is the source of truth, not anyone's memory.
We operate the entire active PowerMTA release line from 4.5r1 through 6.0r3. We do not take new managed contracts on versions where Bird's security backports have wound down, because operating an unsupported PowerMTA in production becomes a compliance risk for any client serving regulated verticals. The same logic applies to OS distributions: we will not take new contracts on RHEL 7 or CentOS 7 because end-of-life timing is incompatible with managed-service operational risk through 2026 and beyond. The matrix below is what we actually operate today, with explicit notes on edge cases.
| PowerMTA version | Linux x86-64 | Windows Server | New contract? | Note |
|---|---|---|---|---|
| 6.0r3 | ✓ supported | ✓ Server 2019/2022/2025 | Yes | Current release, recommended for new deployments |
| 6.0r2 | ✓ supported | ✓ Server 2019/2022/2025 | Yes | Stable, upgrade to 6.0r3 evaluated quarterly |
| 6.0r1 | ✓ supported | ✓ Server 2019/2022 | Yes | Upgrade to 6.0r3 recommended within 90 days |
| 5.0r5 | ✓ supported | ✓ Server 2019/2022 | Yes | Mainstream production, upgrade to 6.x next major window |
| 5.0r1 → 5.0r4 | ✓ supported | ✓ Server 2019/2022 | Yes | Upgrade to 5.0r5 included in first 90 days of contract |
| 4.5r5 (LTS branch) | ✓ supported | ✓ Server 2019 | Conditional | Long-tail clients only, upgrade plan required at contract |
| 4.5r1 → 4.5r2 | ✓ supported | limited | Upgrade required | Mandatory upgrade to 5.x within first 60 days of contract |
| Pre-4.5 (4.0, 4.1, 4.2) | unsupported | unsupported | No | Bird security backports limited, compliance risk for regulated verticals |
Linux distributions actively supported: RHEL 9, Rocky Linux 9, AlmaLinux 9, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Debian 12 Bookworm. Linux distributions we will not take new contracts on: RHEL 7, CentOS 7 (both end-of-life), Ubuntu 18.04, 20.04 (mainstream support ended), older Debian. Existing clients on older OS get migration plans included in the first 90 days of contract; the migration is part of the managed service scope, not a billable add-on. Windows Server PowerMTA represents about 8 percent of our managed contracts and is supported across Server 2019, 2022, 2025. About 92 percent of new managed contracts onboard on Linux; the gap reflects the industry consolidation around Linux for production email infrastructure.
Three tiers calibrated to single-node managed, multi-node cluster managed, and enterprise multi-region. Each tier has explicit response windows, explicit deliverables, explicit communication cadence. Every tier ships with the Git-backed runbook. Every tier carries the monthly SLA report. The differences live in coverage hours, response time, communication cadence, and depth of strategic review. No hidden enterprise tier exists. The ladder above $9,890 per month is custom-quoted for clusters above 20 nodes or multi-region deployments above two regions. Custom-quoted is rare. About 60 percent of inbound managed contracts land at single-node ($1,890). 30 percent at cluster ($4,890). 8 percent at enterprise ($9,890). 2 percent at custom-quoted above enterprise.
| Coverage dimension | Single-node | Cluster | Enterprise |
|---|---|---|---|
| Production-down response window | 4h business hours, best-effort after-hours | 2h response 24x7 | 1h response 24x7 + 15min ack guarantee |
| Senior engineer assigned | Pool rotation | Primary + secondary | Dedicated account engineer |
| Stakeholder communication cadence | Monthly SLA report only | Weekly check-in call + monthly report | Biweekly review + monthly report + quarterly stakeholder |
| Disaster recovery drill | Not included | Annual | Quarterly |
| Multi-region failover orchestration | Not applicable | Not included | Included up to 2 regions |
| Post-mortem delivery for production-down | Within 5 business days | Within 3 business days | Within 2 business days |
| Version upgrade window | Quarterly review, deferred coordination | Quarterly review, scheduled jointly | Monthly review, joint approval workflow |
The four realistic paths a SaaS platform takes when continuous PowerMTA operation becomes the bottleneck. Each path has tradeoffs, each fits a specific situation, and each carries operational risks that rarely surface in the initial sales conversation. The comparison below uses a representative scenario: a B2B platform running 3 PowerMTA nodes handling 8 million monthly messages, where the in-house team has strong general infrastructure capability but no PowerMTA-specific operational depth.
| Operating model | Time to coverage | Year-1 cost | Continuity risk | Strategic depth |
|---|---|---|---|---|
| Hire senior PowerMTA SRE in-house (US/CA) | 4-9 months search + 2-3mo onboarding | $220K loaded + recruiting fees | High (single point of failure) | Highest (institutional context) |
| Postmastery managed retainer | 30-45 days | €55K-€95K (€4-€8K/mo + audit) | Low (vendor pool) | High (deliverability strategy depth) |
| Generic infrastructure agency | 14-30 days | $30K-$60K | Medium (no PMTA specialization) | Low (general SRE not domain-specific) |
| EMP managed (Cluster tier) | 14-21 days | $58,680/yr ($4,890/mo) | Low (4-engineer pool) | High operational, partner-coordinated strategic |
Monthly contracts. Initial commitment of 90 days at contract start (we need at least one full operational cycle to deliver value), then month-to-month. No annual lock-in, no auto-renewal traps, no early-termination fees beyond the initial 90 days. Bring your own Bird license. The license relationship stays directly between you and Bird; we operate the engine, you own the contract.
One PowerMTA node. Business-hours coverage.
2-6 nodes. 24x7 coverage. Weekly check-in.
7-20 nodes. Multi-region. 1h response 24x7.
"What guarantees do I have that you'll still be operating in 12 months?"
Fair question, asked specifically because managed service has historically had a high vendor mortality rate in the email infrastructure space. EMP business continuity: 16 years of continuous operation since 2010, never missed a payroll cycle, never lost a managed client to operational failure on our side. The senior engineer pool of 4 represents combined 47 years of PowerMTA exposure with primary plus secondary plus tertiary coverage on every account. Contract continuity provisions: the Git-backed runbook is portable from day one, so if EMP ceased operation tomorrow, your team has the full operational context to continue running the infrastructure or hand it to another vendor without a transition project. Financial transparency on request: for Enterprise tier contracts we provide audited financial statements under NDA during procurement. Where we cannot guarantee: we are smaller than Postmastery, smaller than Bird's professional services. If your procurement team has a hard requirement for a vendor with $50M+ revenue, we will not pass that filter and the recommendation is to engage Postmastery directly. About 12 percent of inbound discovery calls have a procurement requirement we do not meet, those conversations end honestly during qualification rather than after a failed RFP.
"Why should I trust an operator from Panama on production PowerMTA?"
Geography is irrelevant to MTA operational expertise; production exposure is what matters. EMP has operated PowerMTA since 2010, before Bird acquired Port25, across release cycles 4.x through 6.0r3. Senior engineering staff hold combined 47 years of hands-on PowerMTA production exposure across deployments handling 500K to 100M monthly messages. Latency from Panama to mailbox provider regions: Panama-to-US-East 25-35ms, Panama-to-EU 110-140ms; for managed-service operational tasks (configuration changes, log analysis, incident response) the latency is irrelevant, and for production traffic the MTA is hosted in your chosen region not in Panama, so client traffic never crosses the operator's geography. Jurisdiction posture: our infrastructure is operated under Panama Ley 81 which sits outside the US CLOUD Act, which is a feature for clients who specifically prefer that posture for their operational vendor. Communication: all senior engineers operate fluent English at technical depth; written communication, video calls, runbooks, and post-mortems are delivered in English by default. Spanish is available on request. About 18 percent of our active managed contracts are with US-based clients, 22 percent EU, 14 percent UK, the rest Latin America and Canada.
"Can I migrate from Postmastery managed to EMP managed without operational disruption?"
Yes, this happens. About 6 percent of our active managed contracts were previously on Postmastery managed support and migrated to EMP managed primarily for cost reasons. The migration takes 14 to 21 days and follows a standard handover protocol: week one we ingest the existing operational context (current sysctl values, virtual-mta config, alert thresholds, runbook artifacts if Postmastery delivered them), week two we shadow-monitor in parallel with Postmastery still operationally responsible, week three we take primary operational responsibility with Postmastery on standby for context questions, week four Postmastery contract terminates per their notice period. What we do not do: bash Postmastery during the migration. They are an excellent vendor, the cost difference reflects geography not capability, and our migration playbook explicitly avoids any client conversation that would damage the prior vendor relationship. About 40 percent of clients who migrate from Postmastery to EMP eventually return to Postmastery for specific deliverability strategy work while continuing managed operation with EMP — that hybrid model works well and we recommend it openly when it fits.
"How do you handle the case where we want to migrate from PowerMTA to KumoMTA mid-contract?"
The managed service contract is engine-portable. Same monthly fee covers PowerMTA managed today and KumoMTA managed tomorrow if you migrate during the contract term. The migration itself is a separate scope of work: we have completed 6 production PowerMTA-to-KumoMTA migrations between 2024 and Q1 2026 (and 3 the other direction when teams determined Lua scripting complexity exceeded license savings). Migration scope typically runs $14K-$28K depending on configuration depth and is independent of managed contract pricing. The strategic question behind the migration is real: KumoMTA's Apache 2 license eliminates the recurring Bird license cost which can be substantial at high volume, and KumoMTA's modern Rust-based async runtime handles burst patterns elegantly. The tradeoff: Lua-based configuration has a steeper learning curve, the operational maturity of KumoMTA in production is shorter than PowerMTA's 25-year track record, and the ecosystem of third-party tools (monitoring exporters, log parsers) is less developed. Our honest take: migrate to KumoMTA when license cost dominates your budget conversation, stay on PowerMTA when operational risk tolerance is low. We deliver excellent results either way, the migration decision should be driven by your business not by our recommendation.
"What's your experience with multi-tenant ESP architectures specifically?"
ESP architecture is a specialized subset of PowerMTA managed work where the operator needs to understand virtual-mta-per-tenant design, IP pool segmentation by tenant reputation tier, accounting log shipping per tenant for billing reconciliation, suppression list management across tenant boundaries, and FBL routing logic that respects tenant isolation. Approximately 30 percent of our active managed contracts are multi-tenant ESPs ranging from 8 tenants to 240 tenants on a single PowerMTA cluster. The patterns we have seen most frequently: per-tenant virtual-mta with concurrency caps tuned to tenant traffic shape rather than global, IP pool segmentation by tenant LTV (premium tenants get warm IPs with established reputation, freemium tenants share a pool with shorter lifetime, abuse-prone tenants isolated to dedicated reputation-recoverable pool), accounting log shipping with tenant_id annotation for downstream billing systems. Where multi-tenant operation gets hard: isolation incidents where one tenant's misconfiguration affects shared infrastructure reputation, requiring rapid quarantine procedures. We have written runbook entries for tenant-isolation procedures across 18 production incidents. What we do not take: multi-tenant ESPs operating sub-optimally on cost-per-tenant economics where the proper architectural fix is product-side rather than infrastructure-side. We say so during discovery.
"What if the senior engineer assigned to my account leaves EMP?"
Operational continuity is structurally engineered to survive any single engineer departure. Three layers of resilience: Layer 1 is the Git-backed runbook which captures every operational decision with the reasoning, so any senior engineer in the pool can pick up the account from the runbook even without prior context on your specific deployment. Layer 2 is the primary plus secondary plus tertiary assignment model: every active client account has a primary engineer responsible for day-to-day operation, a secondary engineer paired in shadow mode who attends weekly check-ins and reviews monthly SLA reports, a tertiary engineer cross-trained on the account configuration. Engineer rotation between primary and secondary roles happens quarterly to keep multiple humans current. Layer 3 is the team-level review cadence: every active account is discussed in our weekly internal operations review where any engineer can raise context questions and any account anomaly is visible to the full team. What this means for the client: the account survives an engineer departure with continuity of operational context, no period of degraded service, no transition project. What we cannot eliminate: personal rapport with a specific engineer is real, and replacing that takes time. We disclose engineer rotations to clients proactively, including departures, and the new primary engineer always reaches out within the first week of the rotation to introduce themselves and review open operational items.
You bring the Bird/Port25 license. EMP is independent of Bird. Practical implications:
About 70% of inbound managed inquiries already hold an active Bird license. The other 30% are evaluating PowerMTA vs alternatives; we coordinate unbiased technical comparison.
Calibrated alert ruleset combined with scheduled reviews:
Where in-house wins: deep institutional context, ownership of long-term roadmap. Where managed wins: faster ramp, lower per-month cost, no continuity risk, immediate access to patterns from 60+ deployments.
The managed service contract is engine-portable. Same monthly fee covers PowerMTA today and KumoMTA tomorrow if you migrate.
Monthly SLA report covers eight measurement axes:
6-page PDF first Monday each month + continuous read-only Grafana dashboard access.
Discovery format: 45-minute video call covering your current PowerMTA stack, version, OS distribution, sustained volume, peak burst pattern, mailbox provider distribution, current pain points, in-house engineering capability, and procurement constraints. Output of the call: explicit fit verdict (managed service is right for you, not right for you, OR you should talk to a specialist partner first), proposed managed tier with rationale, proposed onboarding timeline, and a draft Statement of Work delivered within 48 hours of the call. We sign mutual NDA before any technical detail is exchanged. About 70 percent of discovery calls convert to engagement, 18 percent get redirected to alternatives (Postmastery, in-house upskilling, KumoMTA self-host), 12 percent decline based on procurement constraints we cannot meet. The discovery call is genuinely diagnostic, not a sales pitch in disguise.
