Stalwart vs Postfix and Dovecot: which to choose

Stalwart vs Postfix and Dovecot: when each one fits

A mail team deciding between its existing Postfix and Dovecot pairing and a single server should start with what the mail service must do on day one. Stalwart fits a single-server or small clustered footprint, teams that need JMAP alongside IMAP, and organizations that also want CalDAV and CardDAV from the same process. It is also a reasonable choice when the team accepts a per-mailbox license decision and is comfortable operating a newer Rust-based server. The classic pair fits better when the team already runs Postfix and Dovecot well, has local configuration and Sieve or policy scripts it depends on, or needs the carrier-scale clustering that the commercial Dovecot Pro line is marketed for.

The decision turns on five questions. First, protocol needs: whether JMAP clients matter to your users or IMAP and SMTP are enough. Second, clustering model: Stalwart clusters through peer-to-peer coordination or with Kafka, Redpanda, NATS or Redis, while Dovecot 2.4 Community no longer ships the replicator and points operators to NFS or another shared filesystem. Third, storage backend: Stalwart supports PostgreSQL, MySQL, SQLite, RocksDB, FoundationDB and S3-compatible storage, so confirm which of these your operators already run. Fourth, licensing tolerance: Stalwart is AGPL-3.0 for Community use and sold under a proprietary Enterprise license, and Dovecot's code is MIT or LGPLv2.1 depending on the directory. Fifth, skills: a team fluent in Postfix and Dovecot configuration should price the retraining time before it migrates.

Before committing, run a short proof of concept on a copy of your own mail flow. Export a representative set of mailboxes, check the Dovecot 2.4 removals against your current configuration, including the fts-lucene and fts-squat plugins and any dsync scripts, and confirm the Stalwart feature set covers your filtering and client requirements. Ask your vendors for written answers on support scope and licensing, and record the rollback path. For a current license schedule, see the Stalwart pricing page.

Which mail stack fits which team

This table maps common team situations to the stack that fits them better, with the condition attached to each choice. Read each row against your own mail volume, staff skills and feature needs, because the better fit changes when the condition changes.

Scenario	Better fit	Why and under what condition
Small team that wants one service to install and run	Stalwart	Stalwart ships SMTP, IMAP, JMAP and CalDAV or CardDAV in one server, so there are fewer components to patch and monitor. This holds if the team is comfortable with a newer project and has no hard need for a specific Postfix or Dovecot setting.
Team that already runs Postfix and Dovecot well	Postfix and Dovecot	Existing runbooks, monitoring and staff experience have real value and migration carries risk. Stay put unless a specific requirement below applies.
Team that needs JMAP plus CalDAV and CardDAV from one server	Stalwart	Stalwart lists JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV in one product. Confirm that every client you support works with the protocols you enable before committing.
Operator planning clustered storage on a shared filesystem	Confirm with both vendors	Stalwart clusters through peer-to-peer coordination or Kafka, Redpanda, NATS or Redis, while Dovecot 2.4 Community removed the replicator and points to NFS or another shared filesystem. Test failover on your own storage before choosing.
Operator who needs commercial clustering or high availability at carrier scale	Dovecot Pro or Stalwart Enterprise (evaluate)	Dovecot Pro is marketed for carrier and enterprise scale with its Palomar architecture. Stalwart Enterprise is licensed per mailbox and includes support from 150 mailboxes. Request written architecture and support terms from each vendor.
Team that depends on Dovecot Community features removed in 2.4	Postfix and Dovecot 2.3 or Stalwart (plan the move)	Dovecot 2.4 removed the replicator, Director support, fts-lucene and fts-squat. If your setup uses any of these, stay on a supported 2.3 path or plan a migration to Stalwart or Dovecot 2.4 alternatives such as fts-flatcurve.
Team that relies on Lucene or Squat full-text search	Confirm before deciding	Dovecot 2.4 replaced these plugins with fts-flatcurve or fts-solr. Stalwart's search behavior is not covered by the facts here, so test indexing and search results with your own mailboxes.
Team with no one skilled in Rust or Stalwart's configuration model	Postfix and Dovecot	Operating effort depends on the people you have. Postfix and Dovecot have a long, widely documented operating history, so hiring and training are easier.

How Stalwart's single server differs from the Postfix and Dovecot pipeline

A classic mail stack is a chain of separate daemons, each with its own configuration, storage expectations and upgrade cycle. Stalwart collapses protocol handling, storage and spam filtering into one process, which changes what you upgrade, what you troubleshoot and what you monitor. The cards below compare the two shapes on the points that matter to a mail team.

Protocols in one process

Stalwart serves SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV and WebDAV from a single server. A classic pairing splits these across Postfix for SMTP and Dovecot for IMAP and POP, with calendar and contact sync usually handled by a separate groupware component. Check which clients in your environment depend on JMAP, CalDAV or CardDAV, because those are the protocols where the two shapes differ most in how many services you must configure and secure.

Separate MTA and mailbox services

In a Postfix and Dovecot stack, Postfix accepts and relays mail while Dovecot stores and serves it, and each has its own main configuration, logs and failure modes. A message can be accepted, queued and delivered correctly while the IMAP service is down, or the reverse. Stalwart's single process removes the hand-off between daemons, but a mail team still needs to confirm how its logs and queue inspection map onto the tools they already use.

Spam and search as added components

A classic stack usually adds Rspamd or a similar filter for spam and a full-text search plugin for Dovecot, each installed, configured and upgraded on its own. Stalwart includes spam filtering with DNS blocklist checks, greylisting, Pyzor and LLM-driven message analysis in the same server. Confirm whether your policies require a specific filter engine, since moving to a built-in filter changes rule tuning and the evidence you keep for false positives.

Pluggable storage versus shared filesystems

Stalwart stores data in pluggable backends including RocksDB, FoundationDB, PostgreSQL, MySQL, SQLite, S3-compatible storage, Azure and Redis. Dovecot 2.4 removed its replicator from the Community Edition and tells users to rely on NFS or another shared filesystem for multi-server setups. Storage choice therefore decides your backup method, your failover design and the skills your team must have, so write down the backend and the recovery procedure before you compare clusters.

Clustering and high availability

Stalwart clusters through peer-to-peer coordination or with Kafka, Redpanda, NATS or Redis. A Dovecot-based cluster typically relies on the shared filesystem arrangement described above, and Dovecot Pro's Palomar architecture is a separate commercial product. Ask for a written description of how failover, session handling and queue state behave in each design, and test the failure you care about most before you commit.

Upgrades and moving parts

A classic pipeline has several version streams to track, and Dovecot 2.4 changed configuration and removed plugins such as fts-lucene, fts-squat and the dsync symlink, so upgrades need a migration review. Stalwart is one binary with one release stream, which reduces the number of components to patch and monitor. Mailcow and Mail-in-a-Box also use Dovecot for IMAP, so if you run either, the classic pairing is already inside that stack and the upgrade path depends on their release cycle.

Protocols, storage and clustering compared side by side

This table sets Stalwart's single-server feature set against the Postfix and Dovecot pair across protocols, storage, clustering, search, spam filtering and license. Read the Dovecot cells as a picture of the 2.4 Community Edition, since several features were removed in that release. Where a cell says to confirm, check with the vendor or in your own test environment before you decide.

Capability	Stalwart	Postfix and Dovecot pair
Protocols covered	JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV in one server	SMTP through Postfix; IMAP and POP through Dovecot. CalDAV, CardDAV and JMAP are not part of this core pair, so confirm any groupware add-on
Storage backends	RocksDB, FoundationDB, PostgreSQL, MySQL, SQLite, S3-compatible storage, Azure and Redis	Dovecot 2.4 guidance for shared mail storage points to NFS or another shared filesystem; confirm supported options with the Dovecot documentation
Clustering	Peer-to-peer coordination, or Kafka, Redpanda, NATS or Redis	Dovecot 2.4 Community removed the replicator and Director; Lua Director is a small-scale unsupported replacement; Dovecot Pro's Palomar architecture is the paid option
Full-text search	Confirm search capabilities and supported indexing with the Stalwart documentation	Dovecot 2.4 removed fts-lucene and fts-squat; move to fts-flatcurve or fts-solr
Built-in spam filtering	Included: LLM-driven message analysis, DNS blocklist checks, greylisting and Pyzor	Not part of the Postfix or Dovecot core; spam filtering is a separate component you select and operate
License	Dual-licensed under AGPL-3.0 or the proprietary Stalwart Enterprise License	Dovecot is mostly LGPLv2.1, with MIT for some core code; Dovecot Pro is commercial; confirm Postfix licensing with your distribution

Licensing and paid editions for Stalwart and the Dovecot stack

Stalwart is dual-licensed under the AGPL-3.0 and the proprietary Stalwart Enterprise License, so the license you run depends on how you use it. The Community edition is free and has no mailbox limit. Enterprise is a per-mailbox subscription, and its features are activated by a license key rather than by a different binary. This matters for procurement because the paid part is a recurring subscription tied to your mailbox count, not a one-time purchase.

Published prices: The pricing page lists 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, falling to 1.04 euros from 10,000 mailboxes. Quotes above 100,000 mailboxes are handled separately.
Minimum commitment: Enterprise has a 25-mailbox minimum, so very small teams should compare the subscription with the Community edition before buying.
Premium Support: Premium Support starts at 150 mailboxes, with an initial response within 48 business hours. Smaller Enterprise customers use community support.
Downgrade path: Cancelling reverts the server to Community without data loss, according to the pricing page. Confirm the exact steps for your version in writing.
Cost drivers: Your mailbox count sets the subscription cost. Staff time for hosting, upgrades and migration is separate and does not appear on the price list.

Ask the vendor to confirm how mailboxes are counted, including aliases, shared mailboxes and service accounts, before you size a quote.

What drives the running cost of each mail stack

Running cost for a mail stack is mostly people time, storage and recurring support, not the software itself. The cards below separate the one-time costs of moving to Stalwart or upgrading Dovecot from the recurring costs that follow every mail stack, so you can ask the right questions of each vendor and of your own team.

Infrastructure footprint

Stalwart runs as one server, but its storage backend and clustering coordination service decide what you host beside it. Choosing PostgreSQL, S3-compatible storage or a peer-to-peer cluster changes backup scope and failure domains. A Postfix and Dovecot stack instead runs several services, plus a filter such as Rspamd in many installs, each needing its own monitoring and capacity planning. Count the services and data stores you will operate in each design, not just the number of servers.

License spend

Stalwart Community is free with no mailbox limit, and the Dovecot Community Edition carries no license fee either, so license cost starts at zero on both paths. Stalwart Enterprise is priced per mailbox per year, and the published tier rates in the Stalwart pricing page are 2.00 euros or 2.40 US dollars per mailbox for 25 to 499 mailboxes. Dovecot Pro pricing is quote-based, so request a written quote with mailbox count, support level and cluster design before comparing totals.

Staff skills and on-call time

The largest recurring cost is usually the time your engineers spend learning and operating the stack. A Postfix and Dovecot team already knows its configuration files and log patterns, so the skills gap sits in the Stalwart configuration model and its JMAP-first client story. Ask who on your team will own mail delivery failures at 2 a.m., and whether that person can debug a single Rust process as well as a chain of Postfix, Dovecot and filter services.

Vendor support options

Stalwart Enterprise includes Premium Support from 150 mailboxes, with an initial response within 48 business hours. Below that threshold, Enterprise customers rely on community support, so a 100-mailbox organization on the Enterprise license gets a different service level than a 200-mailbox one. Dovecot Pro adds dedicated vendor support, long-term support and proactive updates, but no published prices. Confirm response targets, escalation paths and the support window in writing before you rely on either.

One-time migration and upgrade work

Moving to Dovecot 2.4 removed features that many installs depended on, including the replicator, Director architecture support, the fts-lucene and fts-squat search plugins and the dsync symlink. Each removal needs a replacement, such as NFS or another shared filesystem for replication, fts-flatcurve or fts-solr for search, and doveadm sync or doveadm backup in place of dsync. Treat these as a one-time project with a test mailbox set and a rollback plan, and cost them separately from recurring operations.

Recurring monitoring and blocklist work

Mail operations recur whether you run Stalwart or Postfix and Dovecot. Expect continuous work on queue monitoring, TLS certificate renewal, DNS records for sender authentication, backup restore tests and reputation management, including checks against DNS blocklists. Stalwart's built-in spam filter, with DNS blocklist checks, greylisting and Pyzor, can reduce the number of separate filter components you run, but it does not remove the need to watch deliverability. Ask any vendor or integrator to estimate this work in hours per month for your mailbox count.

Moving mail from Postfix and Dovecot to Stalwart, step by step

This sequence turns a working Postfix and Dovecot installation into a Stalwart deployment with a tested migration path, a parallel-run period and a rollback option at every stage before users are moved.

Inventory protocols, clients and integrations
Your mail team lists every protocol and client in use, including IMAP, POP3, SMTP submission, any ActiveSync or CalDAV and CardDAV clients, mobile devices, scripts, journaling, relays and third-party services that send mail through your servers. Record which Dovecot features and plugins are enabled, which mailbox formats and folder layouts are in use and which users depend on shared or delegated mailboxes. Confirm with the vendor which of these protocols and integrations Stalwart supports in your edition before any design work begins. The step is done when you hold a written inventory that every later step can be checked against.
Map Dovecot 2.4 removals to Stalwart equivalents
Your team checks each Dovecot feature you rely on against the Dovecot 2.3 to 2.4 upgrade guide. Replicator, Director, fts-lucene, fts-squat and the dsync symlink were removed from the Community Edition, so any setup that used them needs a replacement plan, such as shared storage in place of the replicator, doveadm sync or doveadm backup in place of dsync, and a documented search approach in place of the removed full-text plugins. Map each of these to what Stalwart provides, and mark any gap as an open decision with an owner. The step closes with a signed-off mapping table showing each source feature, its target and any feature you will not carry across.
Choose storage backend and clustering model
Decide where mail, metadata and search data will live. Stalwart supports several pluggable backends, including PostgreSQL, MySQL, SQLite, RocksDB, FoundationDB, S3-compatible storage, Azure and Redis, and clusters through peer-to-peer coordination or through Kafka, Redpanda, NATS or Redis. Compare these against your current storage, backup tooling, availability targets and the staff who will operate them. Confirm with the vendor whether your chosen combination is supported for your mailbox count and whether clustering requires an Enterprise license. The step is done when an architecture decision record names the backend, the cluster model, the backup method and the restore test you will run.
Build a staging environment with test mailboxes
Your team stands up a non-production Stalwart instance that mirrors the chosen architecture, with DNS in a test zone, TLS certificates and a set of test mailboxes covering each protocol, client type and folder layout from the inventory. Load representative messages, including large attachments, shared folders and messages with special characters in headers. Test sending, receiving, spam handling and client connections end to end. You know this step is done when every inventory item has a passing test case and the results are recorded in a shared test log.
Migrate mailboxes and messages with doveadm
On the source side, use doveadm sync or doveadm backup where they apply to your current setup, since Dovecot 2.4 removed the dsync symlink and these commands replace it. Run a first full copy to staging, then incremental passes against a copy of production, and compare message counts, folder structure, flags and sizes per mailbox. Mail data and mailbox structure should transfer, but treat that as a claim to verify through testing, not an assumption, and log every mailbox that fails to match. The step is done when a sample of mailboxes in staging matches the source counts and flags across the full mailbox set, with exceptions documented and resolved.
Rebuild DNS, client settings and monitoring
Recreate what does not carry over automatically. Update MX, SPF, DKIM, DMARC, autodiscovery and TLS-related DNS records for the new server, and prepare DNS changes with low lead times so they can be reversed. Reconfigure IMAP, SMTP, JMAP and CalDAV client settings and test each client type, including mobile devices. Rebuild spam rules, allow and block lists, DNS blocklist checks and greylisting policies in Stalwart, and rebuild monitoring and alerting for queues, certificates, authentication failures and storage. The step is done when a checklist of DNS records, client profiles and monitoring alerts has been verified from outside your network.
Run cutover with a rollback plan
Agree the cutover window, the decision makers and the criteria for going forward or rolling back in writing before the change. Keep the Postfix and Dovecot servers running and ready to receive DNS reversal, and perform a final incremental sync immediately before the switch. Move DNS and client profiles in the agreed order, verify mail flow with test messages in both directions, and confirm queue and authentication health. The step is done when the rollback steps have been rehearsed in staging, the go or no-go criteria have been met and the first production messages have been confirmed in both directions.
Operate a parallel run and retire the old stack
Keep the legacy servers available for a parallel-run period agreed in advance, with the rollback plan still active. Review delivery logs, bounce rates, client complaints, spam classification and storage growth daily against the baseline from the inventory. Only after the agreed period passes with no unresolved defects do you decommission Postfix and Dovecot, archive their final backups and document what was retired. The step is done when the sign-off record shows the parallel run closed, the archive is verified by restore test and the legacy hosts are removed from monitoring.

Where mail migrations usually run long

The effort in a Postfix and Dovecot replacement rarely sits in the mail server install. It sits in the clients and the routing behavior that users never see until cutover. Before scoping, confirm the mailbox count, the client mix (desktop, mobile, webmail, shared mailboxes, and any ActiveSync or CalDAV clients), and which protocols are live today, including POP3 if it is still used by a few devices. Each protocol and client pair needs its own test pass against the new server, and those passes tend to expand once a long tail of legacy devices appears. Plan a test matrix before anyone touches DNS. Spam tuning is the second item that runs long. Stalwart ships its own filtering (DNS blocklist checks, greylisting, Pyzor and LLM-driven analysis, as its README describes), while a Postfix and Dovecot stack usually relies on a separate filter chain that the team has tuned for years. Expect a period of false positives and false negatives after the switch, and treat the old filter rules as a baseline to compare against rather than a set of settings to copy across. Full-text search is another source of delay: if the current Dovecot setup uses fts-lucene or fts-squat, Dovecot 2.4 removed those plugins, so the index for every mailbox has to be rebuilt on the replacement engine. Confirm how large the index is and how long a rebuild takes in a staging copy of the largest mailbox. DNS, reputation and skills complete the picture. Cutover touches MX, SPF, DKIM, DMARC and the sending IP reputation, and a sending address change can cause delivery problems that look like server faults. Teams whose runbooks are built around main.cf, master.cf and dovecot.conf need to rewrite them around Stalwart's configuration and administration model, which is a skills change for operators as well as a document change. Implementation is usually fixed-scope when a partner is engaged, with scope, deliverables and timelines agreed in writing before work starts, so gather these inventories first and ask for the cutover, rollback and training items to be listed explicitly.

Questions buyers ask before moving off Postfix and Dovecot

What does it cost to move off Postfix and Dovecot to Stalwart?

The software cost depends on the edition you choose, and the rest of the cost is labor. Stalwart's Community edition is free with no mailbox limit, according to the Stalwart pricing page. Enterprise is a per-mailbox annual subscription activated by a license key, and the published list is 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, falling to 1.04 euros from 10,000 mailboxes, with a 25-mailbox minimum. Labor drives most of the rest: inventory, migration tooling, DNS and TLS work, testing and cutover. Ask any implementation partner for a quote built from a written scope, and ask them to separate one-time work from recurring support and upgrades.

How long does a mail server migration take?

No duration can be stated here without knowing your environment, so treat any single number with caution. The main drivers are mailbox count and total mailbox size, the number of domains and aliases, how many clients and devices each user has, the complexity of sieve or forwarding rules, and how many integrations depend on SMTP, IMAP or authentication settings. Time also depends on how many migration rehearsals you run and how long your coexistence window must be. Ask for a timeline tied to a written inventory and a test plan, not a generic estimate.

What must our team provide before a migration starts?

Plan for four inputs before anyone changes a server. First, a complete inventory of domains, mailboxes, aliases, distribution lists, relay partners, application senders and retention rules. Second, test accounts on each domain so you can verify delivery, folder sync and client behavior before cutover. Third, DNS access to update MX, SPF, DKIM, DMARC, autoconfig and TLS records, plus the ability to lower TTLs ahead of the change. Fourth, a named sign-off owner for each cutover step and for rollback. Missing any of these usually delays the project more than the technical work does.

Can our own team run the migration without outside help?

Yes, if your team already runs Postfix, Dovecot, TLS certificates, DNS and backups, because the skills carry over to operating a single server. You do not need Rust knowledge to deploy or operate Stalwart, but you do need to learn its configuration model, its storage backend choice and its clustering options. Outside review is common for the cutover itself, since a mistake in MX or DKIM records is hard to undo in a day. An independent check of the plan, the rollback path and the first week of monitoring is a reasonable scope to ask a partner to price.

Does Dovecot 2.4 force us to move off Dovecot?

No. Dovecot 2.4 does not require you to change products, but the upgrade guide removes several features from the Community edition, so you need a plan for any that you use. The replicator is gone and the guide points to NFS or another shared filesystem instead. Director architecture support is removed, and Lua Director is described as a small-scale, unsupported replacement. The fts-lucene and fts-squat search plugins are removed in favor of fts-flatcurve or fts-solr, and the dsync symlink is replaced by doveadm sync or doveadm backup. Audit your configuration against the Dovecot 2.3 to 2.4 upgrade guide before choosing between upgrading Dovecot and migrating.

How do Enterprise activation and cancellation affect switching later?

Stalwart's pricing page says Enterprise features are activated by a license key, and that cancelling reverts the server to Community without data loss. That makes the license a commercial control rather than a data lock, but you should still confirm the exact terms in your contract. Ask what features disappear on cancellation, whether any configuration depends on Enterprise-only settings, and how support obligations end. Also ask whether you can export mailboxes and configuration in open formats so a later move to another stack does not depend on any vendor. Record these answers before you deploy, since they shape the exit cost.

How DeployOpen helps teams choose and move mail platforms

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Stalwart or Postfix and Dovecot decision can be tested against your real domains, users and compliance evidence before anything moves. We start from the written scope and the platform choice your team actually needs to make.

How we scope

Written scope agreed before work starts, covering protocols, client access and the mail flows you must keep.
Inventory of existing Postfix, Dovecot and Rspamd settings, mailboxes, aliases, folders and full-text search dependencies.
Decision on storage backend and clustering model, including whether shared filesystem or another design fits your environment.

How we build

Test deployment of Stalwart in your own cloud account, data center or air-gapped network, using your DNS and TLS setup.
Migration rehearsal with a sample of mailboxes, checking IMAP, JMAP, CalDAV and CardDAV clients against your user devices.
Configuration of spam filtering, blocklist checks and licensing, with each Enterprise feature confirmed against the vendor's current terms.

How we hand over

Runbooks for installation, upgrades, backup and restore, and mailbox moves, written for your operations team.
Documented evidence of controls and configuration to support your own compliance assessment, which an independent auditor still performs.
Knowledge transfer sessions so your staff can operate the new platform without depending on DeployOpen day to day.

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover, scoped in writing.
Periodic review of vendor releases, such as Stalwart version changes, with a plan agreed before any upgrade runs.
Quotes follow from the written scope, so ask for a breakdown of one-time migration work versus recurring retainer effort.

Stalwart vs Postfix and Dovecot