Mail transfer agents

Mail transfer agents, from Postfix to PowerMTA

Choosing, configuring, and operating an SMTP server in 2026. Postfix and Exim on the open-source side; PowerMTA, KumoMTA, Halon, MailerQ, and GreenArrow on the ESP-grade side; Postal as a full platform-in-a-box.

10 guides Open source + commercial Updated 2026

An MTA is where email actually gets sent. It is the daemon that accepts messages from your applications, queues them, negotiates TLS with receivers, retries on failure, and produces the bounce logs you eventually parse. Choose wrong and every deliverability decision downstream is harder.

This hub covers the ten MTAs used most in production today, split across three tiers. Open-source infrastructure MTAs (Postfix, Exim, Sendmail) run most of the world's general-purpose mail servers and app relays. Commercial and high-volume MTAs (PowerMTA, KumoMTA, Halon, MailerQ, GreenArrow) are what ESPs, high-volume SaaS, and multi-tenant platforms actually deploy when deliverability control and per-tenant throttling become non-negotiable. Postal sits on its own as a platform-in-a-box: open source, but with the web UI, APIs, IP pools, and multi-tenant model of a SendGrid clone.

Each guide starts with the operational reality: what breaks, what scales, what production traffic looks like. Then configuration essentials, security hardening, integration with modern authentication (SPF/DKIM/DMARC), and the specific pitfalls that ship to production. Start with the Ultimate MTA guide if you need to pick an engine; jump directly to a specific MTA guide if the choice is already made.

Frequently asked questions

Which MTA should I use in 2026?

It depends on volume and use case. For general-purpose mail servers, app relays, and modest transactional traffic: Postfix is the safe default (or Exim if you inherit it). For high-volume ESP-style or multi-tenant sending: PowerMTA if you want commercial support out of the box, KumoMTA if you want open-source with modern Rust + Lua design, Halon if you want fine-grained scripting for security-heavy flows, MailerQ if your architecture is already queue-based (RabbitMQ). For a full platform with UI, APIs, and multi-tenant orgs: Postal. For legacy Sendmail installs: plan migration.

Postfix vs Exim: what is the practical difference?

Postfix separates duties across many small processes (smtpd, cleanup, qmgr, local, smtp), each doing one thing. Exim runs mostly as a monolithic process with routers and transports configured in one big file. Postfix is easier to reason about and harder to break; Exim is more flexible but more surface area for misconfiguration. For fresh deployments Postfix wins; for cPanel-style shared hosting Exim persists because it is what the panels installed.

PowerMTA vs KumoMTA: which one should ESPs pick in 2026?

PowerMTA is the long-standing commercial engine: mature, config-driven, backed by vendor support, and deployed at most of the top-tier ESPs. KumoMTA is the modern open-source alternative built by ex-PowerMTA veterans, with a Rust core, Lua policies, and a cloud-native deployment model. If you want commercial backing and a known-good product, PowerMTA. If you want open-source with equivalent throttling, IP pools, and per-tenant control at zero license cost, KumoMTA. Both are valid; the choice usually comes down to procurement culture and DevOps maturity.

When does Halon or MailerQ make more sense than PowerMTA/KumoMTA?

Halon shines when you need programmable policies (its HSL scripting language) for security, filtering, or complex custom flows. It is popular among ISPs, hosting providers, and enterprises where mail policy is intricate. MailerQ shines when your architecture is already queue-based: it centers on RabbitMQ with JSON messages, so plugging it into an event-driven microservice stack is natural. PowerMTA and KumoMTA are more general-purpose; Halon and MailerQ pay off when their specific model fits your architecture.

What is Postal and how does it differ from a bare MTA?

Postal is an open-source self-hosted mail delivery platform, not a bare MTA. It bundles an MTA with a web UI, HTTP APIs, webhooks, message logs, IP pools, and multi-tenant organization structure — closer to a self-hosted SendGrid than to Postfix. Use Postal when you want a full platform stack under your own control; use PowerMTA/KumoMTA/Postfix when you only need the MTA layer and will build (or already have) UI, APIs, and control planes on top.

Is Sendmail still viable in 2026?

Only for maintenance mode on existing infrastructure. Sendmail is still actively released and can technically run modern setups, but the operator community has largely moved on. Documentation quality lags Postfix by decades, configuration is harder for newcomers, and finding senior sysadmins comfortable with sendmail.cf is a hiring challenge. Plan migration to Postfix (for general-purpose) or to a commercial/high-volume MTA if you have grown into ESP-scale sending.