Self-hosted email, honestly reviewed. What you actually get when you replace Google Workspace with a Go binary and a dedicated VPS.

TL;DR

What it is: A single-binary, MIT-licensed email server written in Go that bundles SMTP, IMAP4, webmail, SPF/DKIM/DMARC, spam filtering, and automatic TLS into one command [1][2].
Who it’s for: Technically capable founders, developers, and privacy-focused teams who want full control over their email infrastructure without assembling a stack of components. Not for non-technical users. Not for teams with zero tolerance for operational risk.
Cost savings: Google Workspace Business Starter runs $6/user/month. A 5-person team pays $360/year. Mox self-hosted on a $6/month Hetzner VPS costs $72/year — for unlimited users on your domain. The math works, if you can handle the operational complexity.
Key strength: No external dependencies. One binary, one quickstart command, one config file. Contrast this with Mailcow or iRedMail where you’re orchestrating 10+ Docker containers [1][2].
Key weakness: Still on v0.0.x versioning — the author hasn’t declared it production-stable. Single-developer project. Email deliverability (getting Gmail and Outlook to actually accept your outgoing mail) remains the hardest part of self-hosted email, and no software solves that for you [2].

What is Mox

Mox is an all-in-one email server built in Go by Mechiel Lukkien. The project started in 2021 with a specific diagnosis: running self-hosted email had become miserable because the “modern email stack” required assembling separate components for SMTP, IMAP, webmail, spam filtering, DKIM signing, and TLS management — often written in C, where small mistakes have large consequences [2].

The answer was a single Go binary that does all of it. No Postfix, no Dovecot, no Rspamd, no separate cert renewal daemon. You download one file, run mox quickstart you@example.com, copy-paste the printed DNS records, and you have a working mail server [1].

As of this writing, the latest release is v0.0.15, published 2025-04-18. The project has 5,587 GitHub stars and is backed by grants from NLnet (NGI0 Entrust, NGI0 Zero Core, NGI0 e-Commons Fund) and the Netherlands Ministry of the Interior — which is meaningful for an independent open-source project and signals it’s taken seriously in the European digital infrastructure space [2]. The code is cross-referenced with RFCs throughout, and there are automated interoperability tests against Postfix [1].

What Mox is not: it’s not a hosted service, it’s not a managed offering, and it’s not a project that markets itself to non-technical buyers. The website [2] is a clean technical reference page. There’s no SaaS tier, no pricing page for a managed plan, no sales funnel.

Why People Choose It

No substantial independent third-party reviews of Mox were available at time of writing. The analysis below draws from the official documentation, GitHub repository, and the broader known trade-offs of self-hosted email.

The appeal is architectural. The self-hosted email space has two dominant approaches: (1) Docker-compose stacks like Mailcow and iRedMail that bundle 8–15 containers together, and (2) manual assembly of Postfix + Dovecot + whatever spam and DKIM tooling you prefer. Both approaches demand ongoing coordination between components, version compatibility tracking, and the cognitive overhead of understanding which container owns which concern.

Mox proposes a third path: treat the entire email server as a single application. The upgrade path reflects this — the website explicitly states that upgrades are “mostly a matter of downloading the new version and restarting” [2]. That is not something you can say about a 12-container Mailcow stack.

The people most drawn to Mox tend to be Go developers or technically rigorous sysadmins who appreciate that the code is well-documented, fuzz-tested, and manually verified against Thunderbird, iOS Mail, macOS Mail, Android Mail, and Microsoft Outlook, plus the major cloud providers (Gmail, Outlook.com, Yahoo, Proton) [1]. The engineering quality is apparent in the feature set — DANE, MTA-STS, REQUIRETLS, TLSRPT are not “nice to have” additions; they’re what serious email security looks like in 2025, and Mox implements them correctly [1].

The honest reason people don’t choose it: the v0.0.x version numbering. The author hasn’t called it stable. For anything business-critical, that signal matters.

Features

Based on the README and official features page [1][3]:

Core mail transport:

SMTP with extensions — receiving, submitting, and outbound delivery
IMAP4 with extensions for client access
Webmail for browser-based reading and composing
Full support for STARTTLS on both inbound and outbound SMTP

Authentication and deliverability:

SPF, DKIM, DMARC — including DMARC aggregate report generation and reception
DANE (DNS-based Authentication of Named Entities) for inbound and outbound
MTA-STS (Mail Transfer Agent Strict Transport Security)
REQUIRETLS support
Incoming and outgoing TLSRPT (TLS Reporting)

Spam filtering:

Bayesian spam filter that learns per-user from Junk/Non-Junk classifications
Reputation tracking per host, domain, and sender address
Greylisting-equivalent: senders with no/low reputation are slowed down rather than rejected outright; rejected emails are held in a “Rejects” mailbox briefly to catch misclassified transactional mail

TLS and certificates:

Automatic TLS via ACME — works with Let’s Encrypt and other CAs
No manual cert renewal required

Internationalization:

Full support for unicode in email address localparts (EAI/IDNA)
Internationalized domain names

Developer and operational features:

HTTP/JSON API for sending transactional email programmatically
Webhooks for delivery events and incoming messages
Prometheus metrics and structured JSON logging
mox localserve subcommand for running a local-only mail server for testing without any DNS or TLS setup

Admin and configuration:

Web admin interface for domain/account/alias management, DNS record guidance, and status monitoring
Config file is plain text, annotated, and human-readable
Account autodiscovery via SRV records, Microsoft-style, Thunderbird-style, and Apple device management profiles
Built-in webserver for static files and reverse proxying (so mox can share port 443 with your website)

What’s notably absent:

No clustering or high-availability. Mox is a single-instance application.
No built-in mailing list manager.
No calendar or contacts (CalDAV/CardDAV) — for those you need a separate service.
No multi-tenant commercial features — this is a self-hosted tool, full stop.

Pricing: SaaS vs Self-Hosted Math

Mox has no pricing because it’s not a service. The software is MIT-licensed and costs nothing [1].

Your actual costs when self-hosting Mox:

Item	Cost
Mox software	$0 (MIT)
VPS (Hetzner CX22, 2 vCPU, 4 GB RAM)	~$6/month
Domain (if you don’t have one)	$10–15/year
Total year 1	~$87
Total ongoing	~$72/year

What you’d pay otherwise for a 5-person team:

Service	Per User/Month	5 Users/Year
Google Workspace Business Starter	$6	$360
Fastmail (Standard)	$5	$300
Proton Mail (Business)	$6.99	$419
Zoho Mail (Workplace)	$3	$180

Self-hosting Mox for 5 users costs $72/year. Google Workspace for the same team costs $360/year. Over three years, you save roughly $850 versus the cheapest major provider — assuming zero incident costs and no paid help to set it up.

The critical caveat: email deliverability. IP reputation is separate from your software. A fresh VPS IP from Hetzner or Contabo may be pre-flagged in some block lists, or simply have low reputation that causes Gmail to route your outbound mail to spam. No software — including Mox — solves this for you. You’ll need to warm up your IP, monitor your sending reputation, and potentially deal with postmaster tools at Google and Microsoft. Budget time for this; it’s the unglamorous tax on self-hosted email.

Deployment Reality Check

The website claims 10-minute setup [2]. For a developer who’s done this before, that’s plausible. For everyone else, budget more time.

Prerequisites:

A dedicated VPS or server. The quickstart explicitly recommends a machine not already running a webserver, because Mox needs ports 25, 443, 80, 587, 993 [2]. Sharing a web server machine is possible but requires extra configuration.
A DNSSEC-validating resolver (unbound is recommended) [1]
A static IP address
A domain name you control
Root access to configure firewall rules and systemd

The actual install path:

useradd -m -d /home/mox mox
cd /home/mox
# download binary
./mox quickstart you@example.com

The quickstart generates config files, creates an admin account, prints all required DNS records, and outputs a systemd unit file. You copy-paste the DNS records (SPF, DKIM, DMARC, MTA-STS, TLSRPT, SRV for autodiscovery — it’s a non-trivial list), wait for propagation, and start mox [1][2].

Docker is available but not the primary or recommended path — this is meaningfully different from Mailcow or Mailu where Docker Compose is the entire install story.

What can go sideways:

DNS propagation delays. If you’re used to instant feedback, waiting 24–48 hours for all your records to propagate is jarring.
Port 25 blocked. Many VPS providers block outbound port 25 by default to prevent spam. You’ll need to contact support to unblock it, which is not always fast.
IP blocklisting. Check your VPS IP against MXToolbox before committing. Datacenter IP ranges are frequently blocklisted.
TLS certificate bootstrapping. Mox handles ACME automatically, but if your domain’s DNS isn’t fully propagated when mox first starts, certificate issuance fails and you’ll troubleshoot ACME logs.
Pre-1.0 software. The v0.0.x versioning is intentional. The author has explicitly not called this production-stable. That may be conservative — the feature set is mature and tests are thorough — but you carry that risk.

Realistic time for a developer who has provisioned a VPS before: 1–3 hours including DNS propagation wait time. For a first-timer: a full day. If you’ve never set up DNS records or managed a Linux server, self-hosted email is probably not your first infrastructure project.

Pros and Cons

Pros

Single binary, no dependencies. The architectural advantage is real. Upgrades are replace binary, restart. No container orchestration, no version matrix headaches between components [1][2].
MIT license. Use it, fork it, embed it in a commercial product, deploy it for clients. No restrictions [1].
Modern protocol stack. DANE, MTA-STS, REQUIRETLS, TLSRPT — Mox implements the full current spec, not just the 2010-era baseline. Few other self-hosted options get this right out of the box [1][3].
Per-user Bayesian spam filtering that learns from user behavior — not a static ruleset [1].
HTTP/JSON API + webhooks for transactional email make it viable as a replacement for services like Postmark or Mailgun for outbound transactional mail [1][3].
Prometheus metrics and structured logging from day one — you get operational visibility without bolting on additional tools [1][3].
Funded by serious European public-interest grants (NLnet, NGI programmes, Netherlands government) — not a weekend project that could disappear [2].
No external dependencies means no PostgreSQL to manage, no Redis to tune. The data model is self-contained.
mox localserve is genuinely useful for developers testing email flows without a real server [1].

Cons

v0.0.x versioning. The author hasn’t declared stability. This is an honest signal, and you should weight it for production use [2].
Single developer. Mechiel Lukkien is the primary (and as far as public record shows, only) maintainer. If he stops, development stops. The NLnet grants help, but the bus factor is real.
No high availability. Mox is a single-instance server. If it goes down, your email goes down. There’s no built-in clustering or failover.
No CalDAV/CardDAV. Email-only. If you want contacts and calendars, you need a separate stack (Radicale, Nextcloud, etc.).
Deliverability is still your problem. The software sets you up for best practices, but IP reputation is earned not configured. First-time self-hosters consistently underestimate this friction.
Webmail is functional, not polished. The built-in webmail works, but it’s not going to replace Fastmail’s interface for users who want a refined experience. Power users will want Thunderbird or an IMAP client.
DNS record complexity. The quickstart prints a lot of DNS records. For someone unfamiliar with SPF, DKIM, DMARC, MTA-STS, and TLSRPT, this is a learning cliff, not a learning curve.
No third-party documentation or community tutorials at scale. The official docs are good, but if you hit an edge case, you’re reading source code and RFCs rather than finding a Stack Overflow thread.

Who Should Use This / Who Shouldn’t

Use Mox if:

You’re a developer or technical founder who wants to own your email infrastructure and has set up Linux servers before.
You’re running email for a small team or personal domain and paying more than $50–100/year on hosted email that you’d rather reclaim.
You want DANE, MTA-STS, and the full modern email security stack without assembling it from parts.
You build products that send transactional email and want to replace Postmark or Mailgun with something self-controlled.
You value a single binary over Docker Compose orchestration.

Skip it (use Mailcow or iRedMail instead) if:

You want a Docker-compose setup with a polished web admin UI and an active community writing guides in 2025. Mailcow has this.
You need webmail that your non-technical team members will actually use comfortably.
You want CalDAV/CardDAV bundled in.

Skip it (use a hosted service) if:

You’re not comfortable with Linux administration, DNS management, or reading error logs.
Your business can’t tolerate an afternoon of downtime to debug a mail delivery issue.
You need SOC 2 or HIPAA compliance documentation — no self-hosted option gives you this without significant additional work.
Your IP reputation concerns outweigh the cost savings — new IPs require months to establish reputation with the major providers.

Skip it (use Fastmail or Proton Mail) if:

You want privacy without operational responsibility. Proton Mail’s self-hosted option doesn’t exist, but their hosted product is built around end-to-end encryption and is genuinely privacy-respecting. Fastmail is fast and reliable and costs $5/user/month. Sometimes the right call is paying someone else.

Alternatives Worth Considering

Mailcow — Docker-based, 10+ containers, polished web UI, active community. More complex to operate than Mox but significantly more documentation and tutorials available. Has webmail (SOGo), calendar, and contacts.
Mailu — Similar Docker-based approach. Lighter than Mailcow. Good for smaller deployments.
iRedMail — Older, more established, supports more deployment configurations (bare metal, Docker). More complex stack.
Maddy — Another single-binary Go mail server, but significantly less mature than Mox and with a smaller feature set.
Docker Mailserver — Minimal, Docker-based, well-documented, no webmail. Good for developers who want a clean SMTP/IMAP foundation.
Fastmail — Hosted, $5/user/month, genuinely excellent. If the operational overhead of self-hosted email isn’t something you want to carry, Fastmail is the honest recommendation.
Proton Mail (hosted) — End-to-end encrypted, Swiss jurisdiction, privacy-first. No self-hosted option, but worth mentioning for privacy-driven buyers.

For the specific profile of “technical founder who wants to escape Google Workspace costs and is comfortable with a VPS,” the realistic shortlist is Mox vs. Mailcow. Pick Mox if you value simplicity, single-binary upgrades, and a modern Go codebase. Pick Mailcow if you want a bigger community, more documentation, bundled webmail and contacts, and are comfortable managing Docker stacks.

Bottom Line

Mox is the most technically coherent approach to self-hosted email available today. The architectural bet — one binary, no dependencies, correct implementation of the full modern protocol stack — pays off in operational simplicity that the Docker-compose alternatives can’t match. The MIT license, the NLnet backing, and the Go codebase signal a project built to last. The v0.0.x versioning and single-developer reality signal a project that hasn’t fully crossed the threshold into “recommend to anyone” territory yet.

For a technical founder currently paying $30–60/month for hosted email on a 5-person team, the math is clear: self-hosted Mox on a $6 VPS covers your infrastructure costs for a year at what Workspace charges for two months. The question is whether you want to own that infrastructure. If the answer is yes, Mox is the cleanest way to do it. If the setup and ongoing maintenance is the blocker, that’s exactly what upready.dev deploys for clients — one-time setup, you own the infrastructure, the recurring bill disappears.