My main reason to start experimenting with Stalwart is because Dovecot removed their replication feature.
A while back, still on GitHub, someone told me that Stalwart could do that, but the thing is that you replicate the infrastructure, not Stalwart itself.
I’m struggling to get it working. My whole idea is to have Stalwart on two sites, so that if one is down, the other, with a higher MX priority number would receive the mail.
I got so far foundationdb, which I had to install on three nodes to form a cluster. I got Garage, also on 3 nodes.
But I don’t understand how I can have two MX’s configured, one for each node.
I have already understood that, unfortunately, I can’t configure anything per node. It’s all about the cluster: a storage for the cluster, directories for the cluster, etc.
But can’t I have an MX address assigned to my remote site, get Stalwart to get a certificate for it? When it sends e-mail, will it “tag” or identify itself as my remote site or as the main site?
Is my architecture feasible at all with Stalwart?
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
Your architecture is absolutely feasible with Stalwart – you are essentially building a geographically distributed cluster, which is a documented deployment pattern.
Here is how the pieces fit together:
Your storage setup is the right foundation. FoundationDB (3-node cluster) as the metadata store and Garage (3-node) as the S3-compatible blob store are exactly what the docs recommend for distributed/fault-tolerant deployments. All Stalwart nodes share these stores, so the data is the same no matter which node handles a request.
Your Stalwart nodes are just cluster members. You can run one (or more) Stalwart nodes at Site A and one (or more) at Site B. They share the same FoundationDB + Garage backend and coordinate with each other. Configuration is cluster-wide, not per-node – that part you’ve already understood correctly.
Two MX records pointing to two sites – yes, this works. You publish two MX records in DNS:
MX 10 mail-a.example.org – Site A
MX 20 mail-b.example.org – Site B (higher number = lower priority = fallback)
When Site A is down, senders will automatically fall back to Site B. Because both Stalwart nodes share the same storage, mail received at Site B is stored in the same place and will be available when Site A recovers.
On SMTP identity / EHLO / TLS: This is the key nuance. Since configuration is cluster-wide, there is a single defaultHostname setting that all nodes use in SMTP banners and EHLO. The docs show the correct pattern for a load-balanced or multi-node setup: you set defaultHostname to the shared/public identity (e.g. mail.example.org), not to each node’s individual hostname. For TLS certificates, Stalwart selects the right certificate based on the SNI the client presents. So you can have certificates for both mail-a.example.org and mail-b.example.org loaded, and each site’s listener will serve the right one. When sending outbound mail, the server will identify itself with the configured defaultHostname.
Practical recommendation: Give each site its own resolvable hostname for MX purposes (and a matching TLS cert), but consider what you want as defaultHostname for EHLO – typically the primary hostname. Check that your SPF/DMARC/PTR records cover both site IPs so outbound mail from either site isn’t flagged.
@oculos I’ve now managed to answer both of these questions myself, you can see the results.
tl;dr You can add the nodes to your existing domain certificate as additional SAN hosts, and you can adjust your connection strategies based on node_hostname.