Stalwart alternative.
Proven email infrastructure, not a rewrite.

At a glance

The criteria that matter when email is infrastructure for a product or a business. Current as of June 2026.

Stalwart's extra protocols, groupware and clustering are real — see when they tip the decision its way. For everyone shipping transactional and team email, the top of this table is the list that counts.

The verdict

How they differ

"New" is a cost, not a feature

Stalwart reimplements SMTP, IMAP, POP3, JMAP and the DAV protocols from scratch in Rust. It's genuinely ambitious engineering. But for the thing it does — moving your company's mail — newness cuts the wrong way. Postfix and Dovecot have been delivering internet mail since before most SaaS companies existed; every strange edge case, every malformed message, every deliverability quirk has already been hit and fixed in production a million times over.

Vectis Mail keeps that boring, proven engine and puts the modern surface — Go API, React admin, declarative config, orchestrated updates — around it. You get the developer experience without betting your mail flow on a young reimplementation of protocols that took two decades to harden.

An API key, not a JMAP account

Both have programmatic surfaces, so let's be precise about the difference. Stalwart gives you JMAP and webhooks — powerful, but you're integrating against a mail protocol. Vectis Mail gives you the thing applications actually reach for: a domain-scoped API key and a /send endpoint, with batch sending, attachments, per-domain rate limits, delivery analytics, and HMAC-signed inbound webhooks. It's a SendGrid you host yourself, not a server you have to learn a protocol to talk to.

See the API Reference for the full surface.

Updates that undo themselves

Picture the upgrade going wrong at 2am. On Stalwart, an upgrade is a binary or package swap; if a release misbehaves, recovery is whatever you manage by hand, under pressure. Vectis Mail runs every change through a 6-phase orchestrator — snapshot → migrate → pull → deploy → health-check → complete — and any failure automatically rolls back to the snapshot. The Plan/Apply view shows you the diff before you run it. The difference isn't a feature on a checklist; it's whether a bad release is a non-event or a very bad night.

When Stalwart genuinely wins: groupware and scale-out

Here's the honest part. Stalwart speaks JMAP and ships CalDAV/CardDAV/WebDAV, so calendar and contacts live in the server — and it clusters across nodes with pluggable storage. If you're buying a groupware platform or a multi-node cluster, those are real reasons to pick it, and Vectis doesn't compete there today.

But notice what that buyer is doing: replacing Exchange. Most teams reaching for a self-hosted mail server aren't — they're replacing SendGrid plus a pile of mailboxes, and they want it to be simple to run and hard to break. For them, groupware and clustering aren't wins; they're extra surface area to secure, patch and operate. Vectis Mail spends its complexity budget where that buyer needs it: deliverability, the API, and updates that can't take you down.

Migrating from Stalwart to Vectis Mail

It's a standard IMAP-to-IMAP move — both expose IMAP regardless of what's underneath:

1. Stand up Vectis Mail on a fresh VPS via the installation guide, with DNS still pointed at Stalwart.
2. Sync mailboxes with imapsync from Stalwart's IMAP to Vectis Mail's Dovecot IMAP.
3. Generate new DKIM keys on Vectis Mail and publish them alongside the existing ones; run both in parallel during cutover.
4. Re-create Sieve filters as needed — both support server-side Sieve.
5. Point your app at the Vectis sending API — issue a domain-scoped key and swap the endpoint.
6. Cut DNS over: switch MX to Vectis Mail and watch it take over as DNS propagates.
7. Verify + decommission after a few clean days.

If you actively use Stalwart's calendar/contacts, plan where those will live first — Vectis focuses on mail, so that's a deliberate scope choice, not a step in the sync.

Frequently asked questions