WI

WildDuck

Scalable IMAP and POP3 mail server with REST API

Mail Servers ★ 2.1k stars Hard setup EUPL-1.2

WildDuck is a modern, scalable mail server providing IMAP, POP3, and a full REST API for managing mailboxes. It stores messages in MongoDB and is designed for clustered, highly available deployments.

Key features

  • IMAP and POP3
  • Full REST API
  • MongoDB storage
  • Designed for scale

Pros & cons

Strengths

  • API-driven management
  • Horizontally scalable

Trade-offs

  • Requires MongoDB
  • Complex to operate

WildDuck replaces

Last reviewed Sep 13, 2026 · 845 words

WildDuck is for people building a mail service, not people who want a mailbox. It was written by the team at Zone Media in Estonia to run their own hosting business and it shows: every mailbox, address, message and user is an object you create through a REST API, storage is MongoDB rather than files on disk, and the design goal is that any node can die and the cluster does not notice. If your requirement is "provision 500 mailboxes from a script and let customers manage forwarding through my web app", nothing else in the email category is built as directly for that. If your requirement is "my family's email on a VPS", the same architecture is 3 databases and 4 daemons of overhead for a problem Stalwart solves with one binary.

WildDuck alone does not receive or send mail

The repository is the IMAP, POP3 and API server. To have a mail server you deploy, from the same authors:

  • Haraka with the haraka-plugin-wildduck plugin for inbound SMTP on port 25, which validates recipients against the API and delivers into MongoDB.
  • ZoneMTA with its WildDuck plugin for outbound delivery from port 587, with DKIM signing and queue management.
  • MongoDB for messages, users and attachments, and Redis for counters, sessions and pub/sub between components.
  • Optionally Rspamd for filtering, and wildduck-webmail, a plain reference web client the authors describe as a demo rather than a product.

The project's wildduck-dockerized repository wires all of this into one compose stack, and I would start there rather than assembling it by hand; the individual configs are TOML files that reference each other through shared secrets and it takes a full day to get right unaided. Budget 1 GB of RAM as the floor for the stack and more once MongoDB has a real dataset, because Mongo keeps its working set in memory and messages are the dataset.

The API is the product

Every operation is an HTTP call: POST /users creates an account with quota and password, POST /addresses/user/:id attaches an address or a wildcard, GET /users/:id/mailboxes/:mailbox/messages lists mail with pagination, and there are endpoints for filters, autoreplies, forwarding targets, 2FA, application-specific passwords and audit copies. Authentication for the API is a bearer token you set in the config, with optional per-role access tokens. That means an admin panel is whatever you write, because the project does not ship one. Plan for it: with WildDuck you are always one small web app away from a usable service, and that app is your job. The upside is real, though. Migrating 10,000 accounts from a legacy Postfix box is a for-loop, and password resets, quota changes and alias management never require shell access to the mail host.

Storage choices you cannot walk back later

Messages are stored in MongoDB with attachments deduplicated across mailboxes, so 200 people receiving the same 8 MB PDF cost 8 MB once. Backups are therefore MongoDB backups: mongodump or filesystem snapshots of a replica set member, not rsync of a Maildir. If your recovery plan involves reading mail files with a text editor when the server is broken, that plan does not survive contact with WildDuck. The reverse is also true: a 3-member Mongo replica set plus 2 WildDuck nodes behind a load balancer gives you IMAP that survives a host failure with no shared filesystem, which is something Dovecot needs a lot of care to achieve.

Stalwart for a household, WildDuck for a platform

Stalwart delivers SMTP, IMAP, JMAP and a web admin from a single Rust binary with SQLite or PostgreSQL behind it, and covers the entire small-deployment case with a fraction of the parts. Mailcow and docker-mailserver are the Dovecot-and-Postfix bundles most homelabs land on. WildDuck's distinctive wins are the API-first model, horizontal scaling on MongoDB, and a codebase that has been running a commercial provider's production mail since 2017; its distinctive costs are the missing admin UI, the JavaScript-and-Mongo operational profile, and an EUPL licence that some companies' lawyers need a minute with. My general view of whether to host mail at all is in self-hosted email, honestly, and it applies double to a platform that hosts it for other people.

What I'd do

For a personal or family domain: Stalwart, and do not look back. For a hosting company, a SaaS that issues customer mailboxes, or a university lab that needs to provision and revoke accounts from an identity system, WildDuck is the right foundation: start from wildduck-dockerized, put a 3-node MongoDB replica set behind it from day one because converting later is painful, write the 20-endpoint admin panel your operators need before anyone else moves in, and treat Haraka and ZoneMTA as parts of the same product with the same upgrade cadence. As a Gmail replacement for one person, it is a lorry hired to fetch groceries.

Compare WildDuck

17 head-to-head comparisons.

Similar mail servers apps