Building a dedicated MTA stack: choosing between PowerMTA, Postfix and Exim

The MTA decision, looked at honestly

The question comes up often enough that it deserves a structured answer. A team has outgrown shared sending, knows it needs its own outbound infrastructure and now has to pick the mail transfer agent that will sit at the core. The three realistic options in 2013 are Postfix, Exim and PowerMTA. Each has a place, each has strong opinions baked into the design and each rewards different operational profiles.

This piece is not a benchmark comparison. Benchmarks for MTAs tell you what hardware they run on, not what it is like to operate them for two years at scale. The better question is the one most evaluations skip: what kind of sending organization are you going to be, and which MTA fits that organization cleanly once the honeymoon is over.

Before going further, a quick frame: Postfix and Exim are general-purpose open-source MTAs. PowerMTA is a commercial product from Port25 Solutions, designed from the ground up for high-volume outbound. That difference colors everything downstream — including the kinds of problems each one is good at solving. If you haven't yet crossed the threshold from shared hosting to dedicated sending infrastructure, the considerations leading up to this decision are covered in scaling outbound email beyond shared hosting — read that first if the MTA question feels premature.

Side-by-side: the three MTAs at a glance

Postfix: the pragmatic workhorse

Postfix was written by Wietse Venema at IBM in the late 1990s as a safer, cleaner alternative to Sendmail. It has aged remarkably well. The architecture is modular, the configuration is understandable after an afternoon with the docs, and the default security posture is conservative in a way that saves you from a surprising amount of grief.

Postfix shines when outbound traffic is steady, moderate in volume and well-behaved. Most Linux distributions ship it as a first-class package, which means your operations team already knows where the configuration lives, how the queue works and how to read the logs. If you are sending a few million messages a month of well-formed transactional mail, Postfix is almost certainly the right anchor.

Where Postfix starts to fatigue is in per-destination policy richness. Out of the box it treats every receiver roughly the same. You can configure per-transport throttling and destination-specific rules, but the configuration grows complicated fast and the tooling to manage it remains do-it-yourself. Senders who need to apply different rules to Gmail, Yahoo and Hotmail — different connection counts, different retry schedules, different timeouts — often find themselves writing policy daemons in Perl or Python to extend Postfix's native behavior.

Authentication integration is straightforward. OpenDKIM as a milter is the standard DKIM signing path. SPF configuration is a DNS exercise, not a Postfix one. The Postfix community has documented the plumbing in depth.

Postfix 2.10 — outbound-focused main.cf skeleton# /etc/postfix/main.cf

# Identity
myhostname             = mail-01.example.com
mydomain               = example.com
myorigin               = $mydomain

# Relay role — we send, we don't accept from the outside
inet_interfaces        = all
inet_protocols         = all
mynetworks             = 127.0.0.0/8 10.0.0.0/8
smtpd_relay_restrictions = permit_mynetworks,
                           permit_sasl_authenticated,
                           reject_unauth_destination

# Outbound TLS — opportunistic to the world, mandatory to authenticated clients
smtp_tls_security_level         = may
smtp_tls_loglevel               = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# Queue tuning for bulk outbound
default_destination_concurrency_limit  = 20
default_destination_rate_delay         = 0s
smtp_destination_concurrency_limit     = 20

# Per-destination tuning via transport + map
transport_maps = hash:/etc/postfix/transport
# Example entry in /etc/postfix/transport:
#   gmail.com   smtp-gmail:
# Then in master.cf define smtp-gmail with its own concurrency limits

# DKIM signing via OpenDKIM milter
smtpd_milters     = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
milter_default_action = accept
milter_protocol   = 6

The shape of that file is the shape of Postfix operations generally: sensible defaults, parameter-driven tuning, and complexity that grows via lookup tables and external tooling rather than a bespoke grammar. Teams that want to understand exactly what is happening in their mail server appreciate this; teams that want the server to do something genuinely unusual eventually hit the wall where extending Postfix means writing a policy daemon.

Exim: the expressive alternative

Exim is the MTA that ships with Debian by default and with cPanel in most installations. It is older than Postfix by a few years and its configuration language is famously dense. Where Postfix hides complexity behind parameters, Exim exposes it as an explicit configuration grammar with routers, transports and ACLs that can do almost anything.

That flexibility is a double-edged property. Exim can implement per-recipient logic, content-based routing, custom retry timetables and fine-grained policy decisions that would require substantial external code in Postfix. The cost is that Exim configurations become long, interconnected and genuinely hard for newcomers to read. A team that already runs cPanel hosting has an Exim deployment somewhere, whether they want one or not, and extending it is faster than migrating off it.

Operationally, Exim handles moderate-to-high volumes with care. Its queue behavior is good, its logging is excellent, and its ACL system makes it unusually strong at rejecting unwanted mail at SMTP time. For senders whose outbound is mixed with inbound or who run mail on cPanel boxes anyway, Exim is the rational default.

Exim is weaker where Postfix is weaker: per-destination policy at scale becomes unwieldy, and the community tooling for commercial-grade outbound — IP pools, virtual MTAs, per-domain backoff curves — does not really exist. You build it yourself or you reach for a commercial MTA.

Exim 4.80 — ACL-based outbound relay fragment# /etc/exim/exim.conf (fragment)

# Primary hostname; EHLO announces this
primary_hostname = mail-01.example.com

# Relay from trusted networks only
hostlist relay_from_hosts = 127.0.0.1 : 10.0.0.0/8

# ACL for relay control
acl_smtp_rcpt = acl_check_rcpt

begin acl
acl_check_rcpt:
  accept  hosts = +relay_from_hosts
  accept  authenticated = *
  deny    message = relay not permitted

# Routers — run in order; first match wins
begin routers
dnslookup:
  driver          = dnslookup
  domains         = ! +local_domains
  transport       = remote_smtp
  ignore_target_hosts = 127.0.0.0/8

# Transport — how to actually deliver
begin transports
remote_smtp:
  driver              = smtp
  dkim_domain         = $sender_address_domain
  dkim_selector       = mail
  dkim_private_key    = /etc/exim/dkim/${dkim_selector}.private
  hosts_require_tls   = gmail.com : yahoo.com : hotmail.com
  tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt

# Retry timetable
begin retry
*  *  F,2h,15m; G,16h,1h,1.5; F,4d,8h

What you notice immediately is that Exim reads less like a configuration file and more like a small program. The router/transport/ACL model is powerful, and a skilled Exim operator can implement policy that would require external daemons on other MTAs. The price is that the configuration becomes hard for anyone but the original author to maintain, and onboarding a new engineer to an Exim deployment takes weeks rather than days.

PowerMTA: the specialist

PowerMTA is what you choose when outbound is the business rather than a supporting concern. Port25 built it specifically for high-volume senders who needed policy control that general-purpose MTAs do not provide. Virtual MTAs, IP pools, per-domain throttling, per-source routing, rich bounce classification, automatic backoff on receiver pushback, detailed accounting files — these are first-class features, not things you build on top.

The operational model is different from Postfix and Exim. Rather than configuring a single queue that handles everything, you configure multiple virtual MTAs — essentially logical sending engines — that each bind to a specific IP or IP pool with their own rules. Marketing traffic can go out on a pool with looser throttling and aggressive retries. Transactional traffic can go out on a pool with strict rate limits, conservative backoff and dedicated IPs that never handle marketing. Each virtual MTA has its own reputation trajectory at receivers, which is the operational point of the design.

Two considerations make PowerMTA a less obvious choice. First, it is commercial. License costs are not trivial and procurement timelines are not instant. Second, the configuration is substantial. A fresh PowerMTA deployment is not something you stand up on a Tuesday afternoon; it takes a design pass to get the virtual MTA layout, pool assignments, policy settings and signing configuration right.

When PowerMTA pays for itself is when a team is sending tens of millions of messages a month across multiple streams with differentiated reputation needs. At that scale, the control it provides has measurable effects on inbox placement — often enough to justify the license several times over.

PowerMTA 4.0 — virtual MTA configuration with IP pools# /etc/pmta/config

# Global settings
max-smtp-out        400
max-msg-rate        2000/h

# --- Virtual MTAs — each binds to a specific IP and role ---
<virtual-mta vmta-txn-01>
    smtp-source-host 203.0.113.10 mail-txn-01.example.com
    max-smtp-out    200
    max-msg-rate    500/h
</virtual-mta>

<virtual-mta vmta-mkt-01>
    smtp-source-host 203.0.113.20 mail-mkt-01.example.com
    max-smtp-out    200
    max-msg-rate    5000/h
</virtual-mta>

<virtual-mta vmta-mkt-02>
    smtp-source-host 203.0.113.21 mail-mkt-02.example.com
    max-smtp-out    200
    max-msg-rate    5000/h
</virtual-mta>

# --- Virtual MTA pools — group VMTAs for rotation ---
<virtual-mta-pool pool-transactional>
    virtual-mta     vmta-txn-01
</virtual-mta-pool>

<virtual-mta-pool pool-marketing>
    virtual-mta     vmta-mkt-01
    virtual-mta     vmta-mkt-02
</virtual-mta-pool>

# --- Per-destination policy ---
<domain gmail.com>
    max-smtp-out                 40
    max-msg-rate                 3600/h
    backoff-notify-zero-messages true
    use-starttls                 true
</domain>

<domain yahoo.com>
    max-smtp-out                 25
    max-msg-rate                 1800/h
    use-starttls                 true
</domain>

<domain *>
    max-smtp-out                 30
    max-msg-rate                 2400/h
    use-starttls                 true
</domain>

# --- DKIM signing per sending domain ---
<domain-key mail,example.com>
    private-key     /etc/pmta/dkim/example.com.pem
</domain-key>

# --- Accounting — structured CSV for downstream analytics ---
<acct-file /var/log/pmta/acct.csv>
    records         d,b,f,t
    move-interval   1h
</acct-file>

The visible difference between this and the Postfix/Exim configs is how directly the configuration expresses sending intent. "This IP sends transactional, that pool handles marketing, Gmail gets 40 concurrent connections and 3,600 per hour, Yahoo gets 25 and 1,800" — these are first-class statements in PowerMTA. Expressing the same policy in Postfix or Exim requires several external pieces (transport maps, policy daemons, per-transport master.cf entries) that work, but at the cost of configuration that's substantially harder to reason about when something goes wrong at 3am.

A decision tree that holds up in practice

The cleanest way to answer the MTA question is a short set of questions applied in order.

How many messages per month, averaged over a year? Under a million: Postfix or Exim comfortably. One to five million: Postfix or Exim with attention to configuration. Five to twenty million: Postfix with policy tooling or PowerMTA. Twenty million and up: PowerMTA unless you have in-house MTA engineering talent that wants to build the tooling yourself.

How many distinct sending streams do you run? One (all transactional, or all marketing): any of the three handles it. Two to three (transactional + marketing, or application + billing): Postfix or Exim works, but the policy surface starts to grow. Four or more: PowerMTA pays off faster because each stream gets its own virtual MTA naturally.

How differentiated are your destinations? If Gmail, Yahoo and Hotmail all get treated roughly the same, a general-purpose MTA is fine. If you need different per-domain behavior — different connection counts, different retry curves, different alignment — PowerMTA's model saves substantial work.

How operationally mature is the team? A team with one part-time operations person is better served by Postfix's conservative defaults than by PowerMTA's expressive power. A team with dedicated deliverability engineers gets more leverage from PowerMTA.

How important is reporting depth? PowerMTA produces accounting files that feed downstream analytics cleanly. Postfix and Exim logs are useful but require more parsing work. If reputation reporting is a first-class product concern, PowerMTA is easier.

The decision at a glance

Two caveats on that table. First, volume alone is a weak signal — a team sending 30 million highly homogeneous messages per month may do fine on Postfix, while a team sending 5 million across twelve distinct streams needs PowerMTA's structure regardless of the raw number. Second, "recommended" is operational advice, not a rule. Plenty of ESPs run on in-house Postfix forks at volumes far above what this table suggests; plenty of smaller senders deploy PowerMTA for reasons that have more to do with procurement culture than technical fit. The table reflects the typical fit, not the only defensible choice.

Cross-cutting habits that matter regardless of MTA

The MTA is only one piece of the sending stack. Five habits matter regardless of which one you pick:

• Authentication on every message. SPF accurate, DKIM signing at the MTA boundary, clean reverse DNS on every sending IP.
• Bounce handling wired into suppression. Hard bounces stop retries. Period. Soft bounces retry with reasonable backoff.
• Feedback loops consumed. AOL, Yahoo and Hotmail all offer FBL programs. Register, parse the reports, suppress complainants immediately.
• Per-IP, per-domain monitoring. Volume, deferral rate, bounce classification and authentication pass rate, broken out by sending IP and receiving domain. No provider ever looks good on average.
• Warmup discipline. Every new IP gets warmed over two to four weeks before carrying production traffic.

An MTA choice without these habits produces bad delivery regardless of which product sits at the center. Any of the three MTAs with these habits produces good delivery for most senders. Of those habits, DKIM signing is the one that most often gets implemented incorrectly — missing intermediates, mismatched selectors, DNS propagation timing, signing-before-modification ordering — and the operational pattern for getting it right on a production sender is covered in detail in DKIM signing for transactional email. Whichever of the three MTAs ends up at the center of the stack, the DKIM work is the same.

Frequently asked questions

Can I start with Postfix and migrate to PowerMTA later? Yes, and many teams do. The migration is not trivial because the operational model is different, but the ground truth of sending (DKIM keys, SPF records, IP reputation) carries over cleanly. Budget a month for the move.

What about Sendmail? Sendmail is still in production at many sites but is no longer the first choice for new deployments. The configuration complexity relative to what it offers has become hard to justify with Postfix available.

Does PowerMTA replace the need for an ESP? No. PowerMTA is an MTA — it sends mail efficiently and politely. The surrounding concerns — list management, campaign composition, unsubscribe handling, analytics — are separate. Some teams build those around PowerMTA; others integrate PowerMTA with a platform like MailWizz or Interspire. The decision is orthogonal.

What about cloud-based sending services? Cloud ESPs (SendGrid, Mailgun, Mandrill and a few others) are genuinely compelling for product teams that do not want to run infrastructure. They are a different product category from a self-run MTA, with different trade-offs: less control, less cost at small scale, less cost visibility at large scale, and dependency on a third party for reputation. Whether they are right depends on the same questions we walked through above.

A practical closing note

MTA selection is a long-horizon decision. A choice made in 2013 will likely be the sending engine for the next five to seven years. That means the right question is not which MTA is best in benchmarks today, but which one will still be serving the business well when the organization is twice its current size. For most teams, Postfix or Exim carries well into that future. For senders whose volume or stream complexity is growing faster than their operations team, PowerMTA earns the license fee precisely when it is hardest to migrate. Pick with the next few years in mind rather than this quarter.

Continue your evaluation

If this article maps to the sending layer you are building or operating, the pages below go deeper into the commercial and operational side of the same territory.