Mailcow vs Postal vs Stalwart: Self-Hosted Email Server Comparison After the 2026 Releases

Three self-hosted email servers, three meaningfully different answers to "I want to run my own mail." This piece compares Mailcow 2026-03 (the "Moorch 2026" release shipped on 23 March 2026), Postal 3.x as it stands in mid-2026, and Stalwart Mail Server 0.14.1, including the Enterprise edition that landed in early 2026. The intent is operator-focused: which one to pick depends on what you're actually building, and the right answer is not the same for everyone asking.

One piece of context before the comparison: all three projects are open source, all three run on a modest VPS, and all three are mature enough to be in real production somewhere. The difference between them is not quality. It is fit for purpose. Choosing the wrong one of the three because it sounded better in a blog post is the most common mistake we see in managed-infrastructure handoffs from organizations that picked a self-hosted stack themselves before consulting anyone.

What actually changed in 2026 across all three projects

Mailcow's release cadence in 2026 has stayed steady. Two releases have shipped to date: 2026-01 in January (the "Janmooary 2026" update, with new EAS and DAV access controls plus an Rspamd jump to 3.14.1) and 2026-03 in March, codenamed "Moorch 2026," which added forced 2FA setup, password update enforcement, DNS-01 ACME challenge support, and an Rspamd update to 3.14.3-1. The maintainer is The Infrastructure Company GmbH (tinc), and the GitHub repository sits at 12,400 stars with 1,600 forks at the time of writing. Anyone looking for the "establishment" of self-hosted email gets Mailcow.

Stalwart shipped 0.14.1 earlier in the year, after a steady stream of point releases through 2025. The headline 2026 change is the introduction of an Enterprise edition, priced from €2 per mailbox per year at the 25-mailbox tier and dropping to €0.89 per mailbox at 50,000+ mailboxes. The Enterprise build adds LLM-assisted spam filtering (compatible with OpenAI, Anthropic, or any OpenAI-compatible endpoint), account archiving with undelete, live telemetry with metric-based alerting, white-label branding per tenant, and an SLA-backed support contract. The free Community edition continues to receive all the same protocol features. Stalwart's GitHub repository sits at around 8,000 stars with very active development.

Postal's pace has been calmer. The 3.x branch has matured rather than transformed; the headline operator-facing capability is unchanged from a year ago: per-message delivery tracking, webhook events for each send, and multi-organization isolation. The deliberate stability is a feature for the agency and application-integration market Postal serves; predictable behaviour matters more than rapid feature evolution for those workloads.

Three projects, three different problems they solve

The first thing to notice is that Mailcow and Stalwart both want to be your complete email server, while Postal does not. If you need users with mailboxes, IMAP access, calendar, and contacts, Postal cannot give you those things. It was not built to. The question "Mailcow or Postal" is most often the wrong question; it is actually two distinct questions glued together. The right framing is "do I need a mailbox server at all, or am I just relaying outbound traffic from applications?" Once that is decided, the alternatives narrow.

The second thing worth noticing is that Stalwart and Mailcow overlap in capability but diverge in philosophy. Mailcow embraces the proven Linux email stack (Postfix, Dovecot, Rspamd, SOGo) and packages it cleanly. Stalwart builds equivalent functionality in Rust as a single coherent program. Both work. The trade-off is community size and operational familiarity (Mailcow wins) versus footprint, simplicity, and modernness of codebase (Stalwart wins). Picking between them is mostly about which trade-off matters more for your operator profile.

Resource footprint: what you actually measure in production

The marketing claims of the three projects diverge widely on resource requirements, and the marketing is partially accurate but glosses over the under-load reality. Numbers we have measured in 2025-2026 production deployments are below.

The Mailcow numbers are dominated by ClamAV, which is the single largest consumer of memory in the default deployment. Operators who disable ClamAV (a reasonable choice in some contexts; ClamAV's detection rate on modern threats is debatable) see Mailcow drop to about 1.2-1.4 GB resident. Disabling ClamAV is a configuration change in the docker-compose override file rather than a code change, so it is reversible.

Postal's footprint scales mostly with queue depth. A Postal instance handling 50,000 daily sends with very low deferral rate hovers around 700 MB. The same instance during a Gmail throttling event that grows queue depth into the tens of thousands can climb above 1.5 GB. The Rails baseline is fixed; the variable cost is the worker processes draining the queue.

Stalwart's numbers are the genuinely impressive ones. The 100 MB idle figure is not a marketing inflation; it is what the binary actually uses. Under load it grows but stays in the low hundreds of megabytes for the workloads typical of small-to-medium organisations. The Rust runtime has no garbage collector competing for memory, and the codebase is intentionally lean. For VPS deployments on the 1-2 GB tier where every megabyte counts, Stalwart has a structural advantage that the other two cannot match.

Feature matrix where it matters

Capability	Mailcow	Postal	Stalwart
Receive mail (IMAP4, POP3)	Yes	No (outbound only)	Yes
JMAP (RFC 8620)	No	No	Yes — full implementation
Webmail UI	Yes — SOGo	No	Optional (built-in admin only; pair with Roundcube)
Calendar / contacts (CalDAV/CardDAV)	Yes via SOGo	No	Yes — native WebDAV
Antispam filtering	Rspamd (mature)	n/a (outbound only)	Built-in + LLM in Enterprise
Antivirus scanning	ClamAV included	n/a	External integration optional
Per-message delivery tracking	Log-level only	Yes — full dashboard	Yes via metrics + logs
Webhook delivery events	No native	Yes — per-event	Yes in Enterprise
Multi-organisation tenancy	Domain-level only	Yes — first-class	Yes in Enterprise; basic in Community
Prometheus metrics	Limited; community exporters	Limited	Yes — native
Clustering / HA	Custom architecture required	Custom architecture required	Native Raft support
ARC / DMARC / DKIM signing	Yes (Rspamd-managed)	Yes (signing only)	Yes — native
MTA-STS	Yes (2026-01 added for alias domains)	Partial	Yes
ManageSieve filtering	Via Dovecot	No	Yes — native
ACME / Let's Encrypt	Yes (HTTP-01 + DNS-01 in 2026-03)	Manual / scripted	Yes — native

Two cells in that table deserve a moment. Stalwart's JMAP support is the only one in the three; if your roadmap involves email clients adopting JMAP (Fastmail, some newer mobile clients, anything built recently), Stalwart is the only option among these three projects. Native Raft clustering in Stalwart is another item the others don't match; Mailcow and Postal can be made highly available with external load balancers and custom architectures, but it isn't a built-in feature.

Installation and the day-after reality

Installing any of the three on a fresh Linux VPS takes between fifteen minutes and a couple of hours. The harder part is what happens afterwards.

Mailcow's install is genuinely well-documented. Clone the repository, copy the configuration sample, edit a small number of variables (hostname, time zone, admin password), run docker-compose pull and docker-compose up -d. Fifteen minutes to a working server. The day-after reality is the fifteen-plus containers; understanding which of them handles what becomes necessary the first time something misbehaves. Most production debugging in Mailcow traces back to Rspamd configuration (when mail is being filtered as spam when it shouldn't, or vice versa) or Postfix configuration (when delivery is misbehaving). Both Rspamd and Postfix have their own complete configuration systems layered underneath the Mailcow abstractions, and learning where to make changes (Mailcow's UI? Direct config files? Container restart needed?) is a real learning curve.

Postal needs more upfront work. The Ruby on Rails stack must be installed (or run in Docker), MariaDB or MySQL configured separately, RabbitMQ installed, and Postal's own setup wizard run. Operators familiar with Rails find this routine; everyone else encounters a stack they don't have other reasons to know. Documentation has improved through the 3.x branch but remains thinner than Mailcow's. Community support is meaningfully smaller; Postal issues on GitHub get prompt attention but the volume of community-written tutorials is a fraction of Mailcow's.

Stalwart's install is the most elegant of the three. Either run the single binary directly (download from GitHub releases, place at /opt/stalwart/stalwart-mail, configure via TOML, start as a systemd service) or use the Docker image (stalwartlabs/mail-server:latest) with a docker-compose file. Either way, one process, one log source, one place to debug. The day-after reality is the smaller community: when the unusual happens, the Stalwart documentation tends to cover it well and the GitHub discussions are helpful, but the volume of community-written troubleshooting content is the smallest of the three. Stack Overflow has fewer answers; YouTube has fewer videos; blog posts are sparser. For operators who like reading source code, this is fine. For operators who want to Google their way out of trouble at 2 AM, Mailcow's community depth is harder to replace.

Deliverability tooling and the gaps each leaves you to fill

Authentication setup — SPF, DKIM, DMARC, PTR — is identical work regardless of which of the three you pick. All three sign outbound mail with DKIM, all three respect SPF and DMARC on inbound where they accept mail, and all three rely on you to set the DNS records correctly outside the server itself. None of these projects can fix poor IP reputation or compensate for missing authentication records.

What differs is the operational tooling each one gives you for diagnosing what's happening once mail is moving.

Mailcow's deliverability surface is the Rspamd dashboard, plus Postfix logs accessible through the admin UI or directly in containers. The Rspamd dashboard shows what the spam scoring engine thinks of your inbound traffic and lets you adjust thresholds. It is good for inbound diagnostics; for outbound deliverability it is less directly useful because Mailcow itself doesn't produce per-message delivery reports the way commercial ESPs do. You learn an outbound message bounced when the bounce arrives in the postmaster mailbox; you correlate against logs to understand why.

Postal's whole reason for existing is the deliverability dashboard. Every outbound message is tracked individually. The dashboard shows whether the receiving server accepted (250), deferred (4xx), or rejected (5xx) the attempt, along with the full SMTP response text, the IP it was sent from, and timestamps. Webhooks fire on each event so you can pipe delivery data into wherever your operations team needs it. For agencies relaying client mail and needing to explain "why didn't this specific email arrive," the Postal interface is meaningfully easier to work with than digging through Postfix logs.

Stalwart's approach is metrics-first. It exposes Prometheus-format metrics for SMTP connection rates, queue depths, per-domain delivery latency, authentication pass rates, and similar gauges. Pair it with Grafana and you have dashboards as detailed as Postal's, with the additional benefit of being able to slice the data however you want rather than working within Postal's UI. The Enterprise edition adds live telemetry with metric-based alerting on top of the same data. For organisations already running a Prometheus stack, Stalwart slots in naturally; for those without that infrastructure, building it adds work that Postal's pre-built dashboard avoids.

Community size and release cadence (March 2026 baseline)

Project	GitHub stars	2026 releases YTD	Issue activity	External tutorials
Mailcow	12,400	2 major (Jan, March) + revisions	~3,000 issues, high engagement	Extensive across YouTube, Reddit, blogs
Postal	~14,000	Steady minor releases on 3.x	Moderate, prompt maintainer response	Strong in GoHighLevel community
Stalwart	~8,000	Frequent point releases (0.14.x)	Active, smaller volume	Growing; less depth than Mailcow

Star counts are a rough proxy at best. Postal's higher star count partly reflects its longer history and its specific appeal to GitHub-using developers (who star projects more readily than non-developer admins running Mailcow do). Mailcow's release cadence is monthly with named releases tied to the cow-pun calendar (Janmooary, Febmooary, Moorch, Moopril, and so on); each release combines security patches, dependency updates, and feature additions in a predictable rhythm. Stalwart's pace is faster but less calendared; releases come when there is something to release.

Stalwart Enterprise: what changed in early 2026

The Stalwart Enterprise edition arrived in early 2026 and is the most significant change to the project's commercial posture in its five-year history. The pricing scales from €2 per mailbox per year at the 25-mailbox entry tier, dropping to €1.23 per mailbox at 5,000+ mailboxes and €0.89 per mailbox at 50,000+. Licenses are anchored to a hostname domain rather than to specific servers, which means a single license covers unlimited Stalwart instances under that domain.

The Enterprise feature additions are operationally meaningful. LLM-assisted spam filtering integrates with OpenAI, Anthropic, or any OpenAI-compatible endpoint, including local LLM servers; in our testing it modestly improves false-positive rates over the built-in spam engine for organisations with idiosyncratic mail patterns. Account archiving with undelete is useful for compliance scenarios that require recoverable deletes. Live telemetry with metric-based alerts builds on the Prometheus integration to add SLO-style alerting natively. White-label branding per tenant matters for organisations reselling Stalwart-based mail to their own customers. SLA-backed support is the operational comfort factor for production deployments where someone needs to be on the hook when things break.

The Community edition continues to receive all the protocol features and is genuinely usable without Enterprise. The Enterprise pitch is for organisations that want operational guarantees or specific advanced features rather than a tool-gated free tier. The pricing at the upper tiers (€0.89 per mailbox per year) is meaningfully cheaper than Mailcow has any analog for, and the cancellation behaviour (revert to Community with no data loss) makes the commitment lighter than typical commercial software contracts.

Decision tool by use case

The interactive selector below produces a recommendation tailored to your specific deployment. Pick the inputs that match your context.

Where each one breaks at scale

All three projects have a scale ceiling. Knowing where it sits matters for medium-term planning, because hitting a ceiling and then needing to migrate to different software is meaningfully harder than picking the right tool from the start.

Mailcow's ceiling is operational rather than architectural. The Docker Compose architecture scales fine to a few hundred mailboxes and a few hundred thousand daily messages. Above that, the management overhead grows: container coordination, MySQL tuning for the underlying database, SOGo scaling, and Rspamd performance under high message rates all become topics the operator has to engage with directly. There is no hard wall at any specific number; there is a gradient where the management cost rises faster than the value of staying on the same platform. Most Mailcow deployments we see in managed infrastructure that exceed about 2 million monthly messages have either already started splitting traffic to multiple servers or are considering migration.

Postal's ceiling is its outbound focus. It does what it does very well up to several million sends per month. Above that, the bottleneck is usually MySQL holding the delivery-tracking data; the same architecture that makes Postal's delivery dashboard great at small volume becomes a database scaling exercise at large volume. Multi-instance Postal deployments with sharded data exist but are operator-built; the documentation does not lead you there. For agencies and applications at moderate volume, Postal stays comfortable indefinitely. For organisations growing past 5 million monthly sends, the architecture becomes more work than it is worth.

Stalwart's ceiling has not been definitively tested at very large scale because the project is still recent enough that the deployment volume at the top end is small. The Raft clustering should handle horizontal scaling cleanly in theory, and a few production deployments exist running it. The honest answer is that Stalwart at very high mailbox counts (tens of thousands) and very high message volumes is plausible but underexplored compared to Mailcow. The Enterprise edition's pricing scaling down to €0.89 per mailbox at 50,000+ suggests the maintainers expect large deployments; the operational track record for those deployments is still being built.

None of the three is the right tool for bulk email at commercial-ESP scale. For Mailchimp-scale volumes (tens of millions to hundreds of millions per day), the right tools are PowerMTA, KumoMTA, or the managed dedicated infrastructure that combines them with operational tooling. Self-hosted full mail servers and outbound relay platforms are not built for the per-ISP throttling, IP pool round-robin, and bounce-classification feedback loops that bulk email requires. Trying to run bulk sending on any of these three works for surprisingly long before it doesn't, and the failure mode (deliverability collapse, blacklisting) is hard to recover from.

Verdict, in plain terms

Mailcow if you are replacing organisational email. The 2026-03 release is solid, the documentation is the strongest of the three, the community can help with most issues by the time you ask, and the Docker Compose deployment is repeatable. If you have a 20-person company moving off Microsoft 365 to save on per-seat costs, Mailcow on a 4 GB VPS is the boring correct answer. The trade-off you accept is 2 GB of baseline RAM, container management complexity, and Rspamd's learning curve.

Postal if you are doing outbound application or agency relay with per-client delivery visibility. The delivery dashboard is irreplaceable for the agency use case, the multi-organisation model maps cleanly onto client isolation, and the Rails stack is well within the comfort zone of many development teams. The trade-off is that Postal cannot be your only mail server: if you also need users with mailboxes, you need a second piece of infrastructure to serve those users.

Stalwart if you want modern architecture and the efficiency that comes with it, especially on resource-constrained hosting. JMAP support is the only path among these three if you have clients that need it. The single Rust binary deployment is the cleanest operationally, and the Enterprise edition gives you a paid support escalation if you decide you want one. The trade-off is community size and documentation depth; if you like reading source code and writing your own troubleshooting notes, this is a feature rather than a bug.

None of the three for high-volume bulk. PowerMTA, KumoMTA, or managed infrastructure handle that workload at a different category of capability. Trying to repurpose a full mail server or outbound relay platform for bulk sending is a common error that leads to deliverability problems that are not solvable in the chosen tool.

The interactive selector earlier in this comparison encodes these recommendations against the typical input combinations. For deployments that fall outside the typical inputs, the reasoning above is the basis for adjusting the recommendation. We have managed infrastructure clients running Mailcow, Postal, and Stalwart in production today, often alongside the commercial MTAs that handle their bulk traffic; the right answer for any specific organisation depends on which problems are biggest, not on which project has the loudest reputation.