Everyone says don't run your own mail server. We do it for a living. Two-node clustering, deliverability as boring correctness, why inbound hygiene is outbound reputation, and monitoring that connects the way a real mail client does.
Ask around and you'll hear the same advice everywhere: don't run your own mail server. Deliverability is a black art, the big providers will distrust you, one mistake and you're in every spam folder on earth. The advice is mostly right, for a side project. We run mail servers for a living, so this post is the counterpart: what it actually takes to do it properly in 2026. Part 3 of the series.
Mail must survive a machine dying, a kernel patch, a bad deploy. So there is no single mail server at email.eu; there are two Stalwart nodes, mx and mx2, running as one cluster and coordinating through a small shared datastore. The world's mail exchangers see both and will deliver to either. Your mail app talks to a load-balanced address, so a node can drop out and your client doesn't notice.
That sounds like standard engineering, and it is. The reason it's worth saying out loud is that a surprising amount of hosted email, including at providers you'd recognise, is one machine with good intentions. Two nodes is the difference between "maintenance window" and nobody noticing.
Deliverability is reputation, and reputation is the accumulation of boring correctness. The outgoing side of our setup:
dig on them are exactly the customers we want, so the records are there to be checked.The incoming side matters just as much, because inbound hygiene is outbound reputation. We verify DMARC strictly on arriving mail, and we track misbehaving clients by their real addresses. That second point is subtler than it sounds: servers behind a load balancer normally see the balancer's address on every connection, which would make one abusive IP indistinguishable from a legitimate customer. Ours speak PROXY protocol with the balancer, which hands the real client address through, so rate limits and reputation stay precise about who is actually knocking.
TLS on a mail endpoint has a failure mode most monitoring misses: a certificate can be valid, trusted, and still not cover the exact hostname a strict mail client insists on, and a conventional check stays green, because the certificate is, after all, valid. The only question that matters is the one the client asks: does this certificate cover exactly the name I'm connecting to?
So that's the question we monitor. A watchdog connects to the mail endpoints every day the way a real client would and verifies the certificate against a pinned list of the hostnames clients actually use. If a renewal ever drops a name, we hear it from the watchdog the same day, not from a support ticket.
Every mailbox we use ourselves runs on the platform, set up through the same signup and go-live flow as any customer. That's deliberate. If deliverability degrades, we feel it before you do, in our own inboxes, on our own invoices to real counterparties.
Both Stalwart and our webmail speak JMAP, the modern successor to IMAP designed by the people who run Fastmail. IMAP still works for every classic client, but JMAP is why the webmail feels immediate: one efficient connection instead of a chatty folder-by-folder protocol from the nineties. It's also how our control plane manages the mail cluster itself. Betting on the modern protocol while keeping full support for the old one is the same open-standards position we described in Your data is yours: the on-ramp and the off-ramp both stay open.
Next in the series: identity. Seven products, one login, and why the login service gets the same paranoia as the mail cluster.