Stalwart v0.16: A New Foundation
After more than three months of focused work, we are thrilled to announce the release of Stalwart v0.16. This is easily the most ambitious release we have ever shipped, with literally hundreds of new features, improvements, and fixes across every corner of the server.
We will be upfront about something: v0.16 will feel like a new product on first contact. Several long-standing concepts have been reworked, a few have been removed, and many new ones have been introduced. This was a deliberate choice. Stalwart has been under continuous development for nearly five years, and both the feature set and the user base have grown far beyond what the original configuration and management layer was designed for. Rather than keep patching around those limits, we took the opportunity to rebuild the foundation. The payoff is a much cleaner architecture and a long list of features that were simply not implementable before, many of which had been sitting on the community wishlist for years.
Let's walk through the highlights.
A Brand-New WebUI
The WebUI has been rewritten from the ground up. It has a refreshed, modern look, and it resolves a backlog of 76 enhancement requests and bug fixes that had accumulated over the years. If there was something you had been missing, there is a very good chance it is now there.
The most requested addition is also the most consequential: the new WebUI can authenticate against external OIDC providers. Signing in with Keycloak, Authentik, Authelia, Zitadel, or any other standards-compliant identity provider is now a first-class flow, with full support for audience and scope validation, group claims, and PKCE (RFC 7636) for public clients. This has been one of the most frequent community asks, and it is finally here.
Unified Management via JMAP and a New CLI
In previous releases, Stalwart was managed through a REST API that lived alongside its native JMAP interface. In v0.16, the REST API is gone. Every configuration and management action is now a JMAP object, reachable through the same /jmap endpoint that already serves email, calendars, contacts, and files.
The benefits of this change are hard to overstate. JMAP (RFC 8620) is a well-specified, transport-efficient protocol with first-class support for batch operations, push notifications, and fine-grained change tracking. In practice, this means dozens of configuration changes can be applied in a single round-trip, any JMAP client library can drive the management surface, and a single authentication flow covers both mail access and administration. Centralizing configuration inside the datastore as JMAP objects also removes an entire category of operator confusion: there is no longer a split between "settings in a file" and "settings in the database", and in clustered deployments the configuration is consistent across every node by definition.
Alongside the WebUI, we also shipped a brand-new CLI. The new stalwart-cli is built on top of the same JMAP management API and can configure and administer every aspect of Stalwart. It is designed for day-to-day administration, scripted deployments, and infrastructure-as-code workflows. The stalwart-cli apply subcommand takes a declarative plan file and idempotently reconciles the live server state to match it, creating what is missing, updating what has changed, and removing what the plan no longer declares. This fits naturally with Ansible, Terraform, NixOS, and similar tooling, and follows the same pattern used by projects like CockroachDB, Consul, Elasticsearch, and HashiCorp Vault, where infrastructure-as-code tools target an API rather than a configuration file.
The new CLI is also a very pleasant surface for AI agents. Because every operation maps to a well-defined JMAP object with a clear schema, agents can discover capabilities, plan changes, and apply them idempotently without any bespoke integration work.
Automated DNS Management
In previous releases, Stalwart only managed the TXT records required for the ACME DNS-01 challenge. In v0.16, it can take care of every DNS record a modern mail and collaboration server needs: MX, TXT, CNAME, SRV, CAA, and TLSA. The server computes the records your deployment should be publishing and keeps them in sync with your DNS provider automatically.
This covers most of the authentication and discovery story out of the box. SPF, DKIM, and DMARC records are managed alongside autoconfig and autodiscover SRV records, CAA records for certificate issuance authorization (including the accounturi parameter for account-scoped issuance), and TLSA records for DANE. The TLSA records are automatically refreshed when ACME certificates are renewed, so DANE-enabled domains no longer risk a validation gap during certificate rotation.
On the provider side, v0.16 ships support for Route53, Google Cloud DNS, Bunny, Porkbun, DNSimple, and Spaceship, and also supports RFC 2136 dynamic updates signed with SIG(0) for operators running their own authoritative DNS.
Automated DKIM Rotation
DKIM key rotation is one of those tasks that everyone knows they should be doing, and almost nobody actually does, because it is tedious and easy to get wrong. In v0.16, Stalwart takes over the entire workflow. It can generate DKIM keys automatically, rotate them on a schedule, and publish the matching TXT records through the new DNS management layer so that the published keys always match the keys the server is signing with. DKIM keys are now stored in the database alongside the rest of the configuration, which means rotation works naturally in clustered deployments without any manual coordination.
Masked Emails
Masked emails are disposable, per-service email addresses that route to a user's real inbox. Instead of handing out a primary address to every newsletter, shop, or forum, a user can generate a unique masked address for each one. If a service leaks its database or starts sending unwanted mail, the corresponding masked address can be disabled individually, without affecting anything else and without touching the user's real address. It is one of the most effective privacy tools available today, and it integrates cleanly with the rest of the directory in Stalwart.
This feature is part of the Enterprise edition.
Security Enhancements
Security gets a substantial upgrade in v0.16. User passwords can now be checked against the zxcvbn strength estimator at set-time, so weak credentials never make it into the system in the first place. Passwords can also be given explicit expiration and rotation policies, and user accounts can be restricted to specific IP ranges so that an account is only usable from expected networks.
App passwords and API keys receive the same treatment, and then some. Both can now be scoped to a specific set of permissions rather than inheriting the full privileges of the owning account, which means a token used by a single IMAP client or a single automation script can be limited to exactly what it needs. Both also support human-readable labels, expiration dates, and IP address restrictions, so long-lived credentials can be audited, rotated, and confined without having to revoke them entirely.
Taken together, these features make the credentials surface of a Stalwart deployment dramatically easier to reason about and lock down.
Other Highlights
There are many other additions worth calling out. On the account configuration front, v0.16 implements the new Automatic Configuration of Email, Calendar, and Contact Server Settings draft, which is shaping up to replace the fragmented autoconfig and autodiscover mechanisms clients use today, and adds MS Autodiscover V2 support for environments that still rely on it.
The directory layer gains domain aliases, alias descriptions, the ability to disable aliases without deleting them, and, for the Enterprise edition, account archiving and un-deletion and per-domain directory backends. The ACME layer picks up the new DNS-PERSIST-01 challenge, on-demand certificate renewal, and a certificate detail view. Sieve scripts can now be deactivated without being deleted. Clustering is cleaner, with automatic node ID generation, unified cluster management, and a new outbound MTA role for dedicated queue nodes.
On top of all of this, dozens of bug fixes land across the directory, MTA, JMAP, IMAP, WebDAV, CalDAV, OIDC, and storage backends. If you have been tracking an issue, there is a good chance it is resolved in v0.16.
Upgrading
Because of the scope of the architectural changes, v0.16 is a major upgrade with multiple breaking changes. Please do not upgrade a production deployment without first reading the upgrading documentation in full. We also strongly recommend spinning up a fresh v0.16 instance in a container or throwaway VM first, getting comfortable with the new WebUI and CLI, and exporting any settings you build there as an apply plan to replay against production after the migration.
If any questions come up along the way, a dedicated discussion thread for the v0.16 upgrade is open at https://github.com/stalwartlabs/stalwart/discussions/3004. We will be following it closely.
This release has been in the making for over three months, and it represents one of the largest single steps forward in Stalwart's history. Thank you to everyone who filed bugs, contributed code, tested pre-releases, and kept the conversation going in issues and discussions: v0.16 is very much your release too. We cannot wait to hear what you build with it.