stalw.art Paid content

What is Stalwart Mail & Collaboration Server?

Stalwart Mail & Collaboration Server is an open-source, all-in-one server that handles email, calendars, contacts and shared files in a single platform. Instead of running separate services for mail transfer, storage, spam filtering, calendaring, contacts and file sharing, it consolidates them into one server. It is written in Rust and supports the standard protocols most clients already speak: JMAP, IMAP4, POP3, SMTP, CalDAV, CardDAV and WebDAV.

H3 What it actually covers

• Email: SMTP delivery and routing, plus JMAP, IMAP and POP3 access for existing clients.
• Collaboration: Calendars, contacts, file storage and sharing, reachable over both DAV and JMAP.
• Anti-spam: Filtering at SMTP time using a built-in classifier, public blocklists, sender reputation and AI-driven analysis, without a separate daemon.
• Security and scale: Runs as a single node or as a cluster across regions, with encrypted-at-rest mailboxes, automatic TLS via ACME, and transport security features such as DANE and MTA-STS.

H3 Who it suits

It fits teams that want to replace a fragmented mail stack with one service to deploy, configure and monitor, and that value a smaller attack surface. It is also a reasonable fit if you need both legacy protocol support and a modern sync protocol for newer apps.

The main trade-off is consolidation itself: one platform means one configuration to learn and one place to look when something breaks, but it also means less flexibility to swap out individual components the way you could with a stitched-together stack.

H3 Next step

If you are evaluating it, start by checking whether your existing mail clients and any custom apps can connect over the protocols listed above, then compare that against your current stack. The project's own site is Stalwart Mail & Collaboration Server.

How does Stalwart replace multiple legacy mail server components with one platform?

Stalwart consolidates the classic multi-component mail stack into a single server process. Instead of running a separate MTA, message store, spam filter, calendar server, contacts server and file server, you deploy one platform that handles all of those roles and speaks the protocols your existing clients already use.

What gets consolidated

The practical difference is operational: one configuration to learn, one place to look when something breaks, and a smaller attack surface than six services each with their own quirks. Identity is shared across mail, calendars, contacts and files rather than synchronized between separate systems.

Concrete scenario

A small team currently runs Postfix, Dovecot, a standalone spam filter, Radicale and a Nextcloud instance just for file sharing. With Stalwart, that becomes one deployment. Users keep their existing Thunderbird or Apple Mail setup over IMAP and CalDAV; new internal apps can talk JMAP instead. Anti-spam runs in the same process, so there is no filter daemon to monitor or tune separately.

Trade-offs to weigh

• Consolidation means a single point of failure unless you run the clustered mode across regions — the page notes one node or a cluster are both supported.
• You inherit Stalwart's opinions on spam filtering and routing rather than mixing best-of-breed components.
• Migration effort is real: existing mailboxes, calendars and contacts need to move, and any custom MTA rules must be re-expressed.

Next step

List every service in your current mail stack and map each to the table above. Anything that does not map cleanly is your migration risk. Then check the official project pages — Stalwart — for deployment and migration guidance before committing.

How do I migrate from an existing IMAP or Exchange setup to Stalwart?

Migration to Stalwart is best treated as a staged cutover rather than a single switch: keep your existing server running, create accounts on Stalwart, copy mailbox data, then move client and MX traffic once mail is verified. Stalwart natively speaks IMAP, POP3, SMTP, JMAP, CalDAV, CardDAV and WebDAV, so existing clients and calendars can usually be repointed rather than replaced.

Practical migration path

1. Inventory what you actually run. List mailboxes, aliases, distribution lists, shared calendars/contacts, and any rules or forwarding. This determines how much is mail-only versus full collaboration.
2. Stand up Stalwart alongside the old system. Use a separate hostname and test accounts. Because it runs as a single node or a cluster, you can start with one node and grow later.
3. Create users and domains. Mirror your identity layer, then decide which accounts are mail-only and which also need calendars, contacts and file storage.
4. Copy mailbox contents. Use IMAP-to-IMAP sync (for example imapsync or a similar tool) from the old server into Stalwart. Do an initial bulk pass, then a delta pass just before cutover to catch new mail.
5. Migrate collaboration data. Calendars and contacts move over CalDAV/CardDAV; files move over WebDAV. Test shared calendars and address books with one real client before doing everyone.
6. Repoint clients. Existing IMAP/POP3/SMTP clients keep working; newer clients can use JMAP for faster sync.
7. Cut over MX and sending. Move inbound MX records and outbound routing once test mail flows correctly. Stalwart handles SMTP authentication (DKIM, SPF, DMARC, ARC), per-domain routing and queueing without a separate relay tier.
8. Run both in parallel briefly. Keep the old server as a read-only fallback for a few days, then decommission.

Exchange-specific considerations

Exchange migrations involve more than IMAP because of calendaring, contacts and shared mailboxes. Two workable routes:

• IMAP + DAV route: export mailboxes over IMAP, calendars and contacts over CalDAV/CardDAV (or via an intermediate export). Works well for straightforward mail and calendar use.
• Staged coexistence: keep Exchange authoritative for a pilot group while Stalwart serves a test domain, then widen. This is slower but safer for organizations with heavy shared-calendar or delegation use.

Public folders, complex room/resource booking and deep delegation are the areas most likely to need manual remapping, so test those explicitly.

Decisions that shape the migration

A useful next step

Before touching production, build a one-user pilot: create the account on Stalwart, sync that mailbox, connect one desktop and one mobile client, and send/receive test mail with DKIM and TLS verified. If that works cleanly, expand to a department, then the whole domain. Stalwart's own documentation at Stalwart Mail & Collaboration Server and its admin dashboard are the right places to confirm current setup steps.

What anti-spam and phishing protection does Stalwart include out of the box?

Stalwart builds its anti-spam and phishing protection directly into the mail server, so you do not run a separate filtering daemon alongside it. According to the product page, filtering happens at SMTP time — before messages reach a user's mailbox — and combines a statistical classifier, public blocklists, sender reputation, and AI-driven analysis.

What's included, per the page

• Statistical spam filter — a built-in classifier rather than an external service.
• Public blocklists — checks against known-bad sources.
• Sender reputation — evaluates the sending host's standing.
• AI-driven analysis — an additional detection layer on top of the above.
• Phishing handling — the page groups phishing with spam and says both are handled before delivery.

Why "at SMTP time" matters

Rejecting or quarantining during the SMTP conversation means the message never enters the store, so users do not see it and you avoid storing junk. It also means the decision is made with the full envelope context (connecting IP, HELO, sender), which is useful for reputation and blocklist checks that are weaker after the message has been accepted.

Where this is not the whole story

The page describes categories of protection, not tuning options, thresholds, or how to train the classifier on your own mail. Those operational details are what usually determine real-world accuracy. Authentication also does heavy lifting against phishing: the page lists DKIM, SPF, DMARC, and ARC support in the MTA, and DANE, MTA-STS, and TLS reporting for transport security. Treat those as complementary to the spam filter, not a substitute — authentication proves a domain's messages are legitimate, while the filter judges everything else.

Practical next step

If you are evaluating Stalwart against a separate filtering stack, test with a copy of your real inbound stream and measure false positives on legitimate bulk mail (newsletters, ticketing systems, mailing lists) — that is where built-in filters most often need adjustment. Check the documentation for how to review quarantined messages and adjust sensitivity before rolling it out to all users. The project's own site is Stalwart Mail & Collaboration Server.

Can Stalwart scale from a single node to a multi-region cluster?

Yes. Stalwart is explicitly designed to run either as a single node or as a cluster spanning multiple regions. The same platform handles both modes, so you are not switching products when you outgrow one machine.

What that means in practice

• Start small. A single node serves mail, calendars, contacts and files with one configuration to learn and one place to check when something breaks.
• Grow horizontally. The clustered mode distributes load across nodes and regions, which matters if your users are spread across geographies or if you need capacity beyond one machine.
• Queue across the cluster. SMTP delivery queues are described as spanning the cluster, with per-domain routing, so outbound mail does not depend on a single host staying up.
• One identity layer. Mail, calendars, contacts and file sharing share the same identity and storage model, which keeps user provisioning consistent as you add nodes.

Trade-offs worth weighing

Clustering is not free complexity. A multi-region deployment introduces network latency between nodes, data-consistency questions for mailboxes and calendars, and a harder time diagnosing faults than a single host. If your user base sits in one region and fits comfortably on one server, the single-node path is simpler and cheaper to operate. Move to a cluster when you have a concrete driver: geographic latency for users, availability requirements that one host cannot meet, or mailbox volume that exceeds a single machine.

A concrete scenario

A small company starts with one Stalwart node on a VPS, using IMAP for existing desktop clients and JMAP for a newer mobile app. When it opens an office on another continent, users there complain about sync latency, so the team adds a node in that region and routes local traffic to it. The same configuration model and the same client protocols apply throughout.

Next step

Decide by requirement, not ambition. List your availability target, the regions your users actually work from, and your expected mailbox volume. If any of those cannot be met by one host, plan for the clustered path from the start so your storage and identity choices do not need rework later.

For deployment specifics, cluster topology options and current pricing tiers, see the official documentation and pricing page at Stalwart Mail & Collaboration Server.

How does Stalwart handle encryption, TLS certificates, and mailbox security?

Stalwart handles encryption, certificates, and mailbox security as built-in defaults rather than separate add-ons, according to its product page.

Transport encryption and verification. Mail in transit between servers is kept encrypted and verified end to end. The server supports DANE, MTA-STS, and TLS reporting, which are the mechanisms that let sending servers confirm they are delivering to a legitimate, encrypted destination rather than silently falling back to plaintext.

Certificate management. TLS certificates renew automatically over ACME, so administrators do not have to manually track expiry dates or reissue certificates on a schedule. Automatic TLS is described as a default behavior of the server.

Mailbox security at rest. Mailboxes are encrypted at rest. Combined with the memory-safe Rust implementation, the design goal is a smaller attack surface than a stack of separate components (MTA, store, filter, calendar server, contacts server, file server), each with its own configuration and exposure.

Spam and phishing as a security layer. Unwanted mail and phishing are stopped at SMTP time, before messages reach the user. The built-in defenses include a statistical filter, public blocklists, sender reputation, and AI-driven analysis, with no extra daemon to run.

Sender authentication. The SMTP side authenticates senders using DKIM, SPF, DMARC, and ARC, which reduces spoofing and helps your own outbound mail pass checks at receiving providers.

What this means in practice. If you run a small self-hosted mail server, automatic certificates and encrypted-at-rest mailboxes remove two routine maintenance chores that often cause outages or data exposure. If you run at scale, cluster-wide queuing and per-domain routing mean the same security posture applies across nodes instead of per-component.

A practical next step. Before migrating, test one domain end to end: confirm your DNS records for DKIM, SPF, DMARC, and DANE or MTA-STS validate, then send and receive through a client over JMAP or IMAP to verify TLS negotiation and certificate renewal. For operational context, compare notes with the broader self-hosting community at Stalwart Mail & Collaboration Server.