Cloud-based email APIs make a lot of sense up to a point. They handle the operational complexity for you, the per-email pricing scales linearly with use, and you can plug in an SDK in fifteen minutes and forget about the rest. We sell that product too. It works well for the senders it works well for. Most teams should never run their own MTA, and we will tell you that on a discovery call if your volume profile fits the API model better.
But there is a curve. Past a certain volume threshold, usually somewhere between five and ten million messages a month for a single sender or two to five million per tenant in a multi-tenant ESP, the API model starts to feel expensive in two specific ways. The per-email cost compounds into a five-figure monthly invoice that is hard to defend to procurement. And the operational abstractions that the API provides start working against you, because you cannot tune queue behavior, retry policy, or per-receiver throttling the way you would if you owned the MTA layer. The first problem is solvable with a discount or an Enterprise contract. The second is structural. APIs hide the MTA from you on purpose.
For senders past that curve, owning the MTA layer becomes the right answer. You buy or license a real MTA. You provision bare metal. You assign and warm IPs. You configure VirtualMTAs or KumoMTA Lua hooks or MailerQ queue topology. You write your own monitoring around it. You get full control over how mail flows from your application to the recipient mailbox. The trade is operational complexity, but for the sender at scale, the complexity is justified by the cost savings, the deliverability tuning, and the fact that nothing about your sending behavior is at the mercy of an API provider's architecture decisions.
The catch is that almost nobody wants to actually do all of that. Procurement bare metal at a colocation provider, install Linux, install PowerMTA or KumoMTA, configure the queues, set up monitoring, build the bounce handling, train someone on staff to be the MTA operator. That is a six-month project for a team that did not have one before, and the team that does have one is usually busy with their existing infrastructure. The honest answer for most senders past the curve is that they want the MTA layer to behave like infrastructure they own, but they want somebody else to operate it.
That is what this page is about. We provision the bare metal, we install and configure the MTA you choose, we hand you the credentials, and we run the operational layer behind it — or you run it yourself if you have the team. Either way, the MTA is on a single-tenant box that is yours for the contract period, the IP space is yours, the reputation is yours, and we are the people who tune the queues when something behaves oddly. Not a first-line support team in a different timezone. The actual engineers.
And we are operators of all three of the MTAs that matter for high-volume sending. PowerMTA on a 5.x license for customers whose procurement requires commercial. KumoMTA on Rust for new builds where the licensing tax is not justified. MailerQ for stacks already heavy on RabbitMQ that benefit from the queue-first architecture. We have been running PowerMTA in production since 2009, KumoMTA since the public beta in 2023, MailerQ for around four years for the customers who need it. The fact that we are not vendor-locked into one MTA means the recommendation we give you is honest, because we benefit either way.
