Migration guide
Replace PowerMTA
with infrastructure built for MailOps
Eliminate proprietary MTA licensing without giving up the control, traffic shaping, IP management, or operational discipline your sending platform depends on.
KumoMTA is the open-source alternative to PowerMTA for high-volume senders. It combines programmable policy and real-time operational visibility with configuration-as-code, container-ready deployment, and no per-server or volume-based licensing.
A PowerMTA alternative built for long-term infrastructure control
Operating High-Volume
Email Infrastructure
PowerMTA works. Why take the risk? ⌄
A migration does not need to begin with a platform failure. Many organizations evaluate PowerMTA alternatives because the platform continues to work, but its licensing, deployment model, or operational workflow no longer aligns with the organization's long-term infrastructure strategy.
The safest time to evaluate another MTA is while the existing environment remains stable and both systems can be operated in parallel.
Will we lose our IP reputation? ⌄
Changing MTA software does not inherently reset sender reputation. Reputation is primarily associated with your IP addresses, sending domains, authentication, traffic quality, complaint rates, recipient engagement, and sending behavior.
A staged migration allows you to retain existing IPs and domains while validating that KumoMTA preserves the traffic patterns and delivery practices your reputation depends on. Carrying your suppression list and engagement data across as part of the migration means the new platform inherits the list hygiene your reputation is built on.
Can KumoMTA replace PowerMTA virtual MTAs? ⌄
Yes. KumoMTA can segment traffic by tenant, customer, source, campaign type, sending domain, IP pool, region, reputation class, or other message metadata.
PowerMTA's virtual-MTA configuration is not copied directly. Its operational intent is translated into KumoMTA's egress sources and pools, queue routing, shaping, and Lua policy capabilities — and the model differs in a way many teams come to prefer. PowerMTA couples queues to virtual MTAs, so moving traffic between IPs means rerouting queues. KumoMTA assigns the egress IP at delivery time from the pool you define, so retries are not pinned to a struggling IP and removing an IP from rotation does not require manually rerouting mail.
Will we need to rebuild every integration? ⌄
Not necessarily. Existing SMTP injection paths, sending domains, IP addresses, DKIM identities, and many upstream application integrations can usually remain in place. KumoMTA also provides a native HTTP injection API alongside SMTP, which many teams adopt for new services after cutover.
PowerMTA-specific configuration, accounting parsers, command-line scripts, dashboards, and deployment workflows may require translation or adaptation. These dependencies are identified during migration discovery before production traffic is moved.
Do we need Lua expertise? ⌄
Teams can begin with documented configuration patterns and reusable policy examples. Lua becomes valuable when your environment requires dynamic routing, tenant-specific rules, custom authentication, message transformation, automated policy decisions, or deeper integration with internal systems. KumoMTA enterprise support can also assist with policy design and migration.
Can PowerMTA and KumoMTA run in parallel? ⌄
Yes. Running both platforms in parallel is the preferred migration approach. Traffic can be moved incrementally by customer, sending stream, domain, region, or IP pool. PowerMTA remains available as a fallback until each stage has been validated.
Document how PowerMTA is being used today, grouped around four areas:
- Traffic and routing: message injection paths, sources and virtual MTAs, sending IPs and pools, routing decisions, and tenant segmentation
- Policy and authentication: domain-specific rules, throttling and backoff behavior, and DKIM configuration
- Downstream consumers: bounce and complaint processing, suppression lists, accounting outputs, reporting and billing dependencies, and custom scripts
- Operations: monitoring and alerting, and disaster-recovery procedures
This phase identifies which behaviors are essential and which configuration rules may be historical remnants that no longer need to be recreated.
Map PowerMTA concepts into KumoMTA configuration and Lua policy. This commonly covers:
- Traffic segmentation: source and tenant identification, egress pool selection, and virtual-MTA-style segmentation
- Delivery behavior: domain traffic shaping, connection and message-rate limits, queue routing, and retry and backoff behavior
- Message handling: DKIM signing, TLS policy, authentication, and custom headers
- Event flow: event processing, and log and webhook delivery
The objective is not to reproduce every PowerMTA directive word for word. It is to preserve the operational outcome while creating a configuration model that is clearer, testable, and easier to maintain.
Begin with a low-risk traffic segment, such as internal notifications, a single customer, one transactional stream, a dedicated subdomain, or a limited group of established IP addresses.
Compare queue depth, message latency, throughput, SMTP responses, deferrals, bounce classification, resource utilization, authentication, mailbox-provider performance, and logging and event delivery.
This allows the team to validate behavior using real production traffic without committing the entire sending operation. Day-to-day operational tooling maps cleanly in this phase: teams that live in the pmta command line manage KumoMTA with kcli — queue summaries, suspensions, rebinds, and cancels — alongside the HTTP API.
Expand traffic gradually by tenant, stream, domain, region, or IP pool. Maintain PowerMTA as a fallback while each stage is monitored and approved.
KumoMTA may not be the right fit for organizations looking for a fully managed email API where the vendor operates the sending infrastructure, IP reputation, queues, and deliverability systems.
KumoMTA is built for teams that want to operate and control the mail transfer layer themselves.
Is PowerMTA being discontinued? ⌄
There is no need to assume that PowerMTA is discontinued in order to evaluate an alternative.
Organizations commonly consider moving because of licensing costs, deployment restrictions, automation requirements, infrastructure strategy, or a preference for open-source software.
Is KumoMTA a drop-in PowerMTA replacement? ⌄
KumoMTA is a functional alternative, but it is not a configuration-file-compatible replacement.
PowerMTA directives must be translated into KumoMTA configuration and Lua policy. Your domains, IPs, DKIM keys, segmentation strategy, deliverability practices, and operational knowledge can continue to be used.
How long does a PowerMTA migration take? ⌄
The timeline depends on configuration complexity, traffic volume, tenant count, custom integrations, reporting requirements, and the number of sending environments involved.
A straightforward environment may move more quickly. A complex multi-tenant platform with extensive PowerMTA-specific tooling may require a longer parallel-validation period.
Can we migrate without interrupting customers? ⌄
Yes.
PowerMTA and KumoMTA can operate simultaneously, allowing traffic to be moved in controlled stages.
Upstream applications can often continue using the same SMTP-oriented workflow while routing determines which MTA handles each traffic segment.
Can we retain our existing sending IPs? ⌄
Yes.
Existing IP addresses can be assigned to KumoMTA, subject to your infrastructure and network configuration.
Using established IPs helps preserve continuity, although sending behavior and delivery performance should be monitored carefully throughout the transition.
Can KumoMTA handle high-volume sending? ⌄
Yes.
KumoMTA is engineered in Rust for high-performance email delivery and efficient use of infrastructure.
Actual capacity depends on message composition, policy complexity, logging, network conditions, destination behavior, hardware, and deployment architecture. Testing should use your real workload and operational requirements.
How does KumoMTA handle traffic shaping? ⌄
KumoMTA supports destination-specific rate limits, connection controls, queue behavior, retry policies, routing, and egress pools, with per-provider rules defined in configuration and Lua.
Traffic Shaping Automation extends this by adjusting sending behavior automatically from live delivery responses — backing off when a mailbox provider defers, and recovering when conditions clear — so shaping reflects real-time conditions, not just static limits.
What happens to PowerMTA accounting files and reports? ⌄
PowerMTA-specific accounting consumers may need to be adapted.
KumoMTA provides structured logs, metrics, events, APIs, and webhook output that can feed internal reporting, billing, suppression, compliance, and analytics systems. It also processes asynchronous bounces and ARF feedback-loop reports natively, feeding the same event stream.
The migration discovery phase should identify every downstream process that currently depends on PowerMTA output.
Is commercial support available? ⌄
Yes.
KumoMTA is open-source software with free community support. Optional enterprise support, migration assistance, and engineering services are available directly from Kumo Corp.
Is KumoMTA free to use in production? ⌄
Yes.
KumoMTA is licensed under Apache 2.0 and can be used in production without per-message, per-server, or volume-based software charges.
Infrastructure, implementation, and optional commercial support remain separate operating costs.
PowerMTA may still be doing the job it was purchased to do. But your organization's requirements may have moved beyond the operating model it was designed around.
KumoMTA gives MailOps teams a path to retain the control and sophistication of a self-managed MTA while gaining open-source ownership, programmable policy, containerized deployment, real-time observability, and predictable scaling economics.
Evaluate while your current environment is stable, run both systems in parallel, and move traffic when the evidence supports it.
Is PowerMTA being discontinued? ⌃
There is no need to assume that PowerMTA is discontinued in order to evaluate an alternative.
Organizations commonly consider moving because of licensing costs, deployment restrictions, automation requirements, infrastructure strategy, or a preference for open-source software.
Is KumoMTA a drop-in PowerMTA replacement? ⌃
KumoMTA is a functional alternative, but it is not a configuration-file-compatible replacement.
PowerMTA directives must be translated into KumoMTA configuration and Lua policy. Your domains, IPs, DKIM keys, segmentation strategy, deliverability practices, and operational knowledge can continue to be used.
How long does a PowerMTA migration take? ⌃
The timeline depends on configuration complexity, traffic volume, tenant count, custom integrations, reporting requirements, and the number of sending environments involved.
A straightforward environment may move more quickly. A complex multi-tenant platform with extensive PowerMTA-specific tooling may require a longer parallel-validation period.
Can we migrate without interrupting customers? ⌃
Yes.
PowerMTA and KumoMTA can operate simultaneously, allowing traffic to be moved in controlled stages.
Upstream applications can often continue using the same SMTP-oriented workflow while routing determines which MTA handles each traffic segment.
Can we retain our existing sending IPs? ⌃
Yes.
Existing IP addresses can be assigned to KumoMTA, subject to your infrastructure and network configuration.
Using established IPs helps preserve continuity, although sending behavior and delivery performance should be monitored carefully throughout the transition.
Can KumoMTA handle high-volume sending? ⌃
Yes.
KumoMTA is engineered in Rust for high-performance email delivery and efficient use of infrastructure.
Actual capacity depends on message composition, policy complexity, logging, network conditions, destination behavior, hardware, and deployment architecture. Testing should use your real workload and operational requirements.
How does KumoMTA handle traffic shaping? ⌃
KumoMTA supports destination-specific rate limits, connection controls, queue behavior, retry policies, routing, and egress pools, with per-provider rules defined in configuration and Lua.
Traffic Shaping Automation extends this by adjusting sending behavior automatically from live delivery responses — backing off when a mailbox provider defers, and recovering when conditions clear — so shaping reflects real-time conditions, not just static limits.
What happens to PowerMTA accounting files and reports? ⌃
PowerMTA-specific accounting consumers may need to be adapted.
KumoMTA provides structured logs, metrics, events, APIs, and webhook output that can feed internal reporting, billing, suppression, compliance, and analytics systems. It also processes asynchronous bounces and ARF feedback-loop reports natively, feeding the same event stream.
The migration discovery phase should identify every downstream process that currently depends on PowerMTA output.
Is commercial support available? ⌃
Yes.
KumoMTA is open-source software with free community support. Optional enterprise support, migration assistance, and engineering services are available directly from Kumo Corp.
Is KumoMTA free to use in production? ⌃
Yes.
KumoMTA is licensed under Apache 2.0 and can be used in production without per-message, per-server, or volume-based software charges.
Infrastructure, implementation, and optional commercial support remain separate operating costs.
PowerMTA may still be doing the job it was purchased to do. But your organization's requirements may have moved beyond the operating model it was designed around.
KumoMTA gives MailOps teams a path to retain the control and sophistication of a self-managed MTA while gaining open-source ownership, programmable policy, containerized deployment, real-time observability, and predictable scaling economics.
Evaluate while your current environment is stable, run both systems in parallel, and move traffic when the evidence supports it.