MailKite Server: our SMTP + IMAP edges are now open source

TL;DR: the mail-server half of MailKite is now open source: github.com/mailkite/server — the Haraka MX edge, the SMTP submission edge, the IMAP server, a zero-dependency SQLite backend, and a web console. AGPL-3.0. Runs on any Node ≥ 22.5 host: a $5 VPS, Docker, Fly, Railway. Five releases in, it receives real internet mail, dispatches signed inbound webhooks, and relays outbound through a smarthost — including MailKite Cloud itself.

What’s in it

Every component is a stateless protocol head. All state sits behind one small HTTP contract — five IMAP read endpoints, an inbound ingest hook, an SMTP auth check, and a relay endpoint (docs/contract.md). That design is the whole trick: the bundled SQLite backend and MailKite Cloud are just two implementations of the same contract, so the edges and the web console run unchanged against either.

• mta/ — inbound MX (Haraka): accepts on :25, POSTs raw RFC822 to your backend as a signed webhook, with live anti-open-relay recipient checks.
• mta-submit/ — submission (:587/:465): SMTP AUTH for apps that only speak SMTP.
• imap/ — IMAP4 on :993: read your received mail from Thunderbird, Apple Mail, or your agent’s IMAP library.
• api-local/ — the reference backend: one Node process, node:sqlite, zero npm dependencies. Per-domain inbound webhooks (HMAC-signed dispatch with a durable retry queue) and smarthost outbound — point SMARTHOST at any SMTP relay, or set SMARTHOST=cloud to send through MailKite Cloud’s deliverability while keeping storage on your box.
• ui/ — the web console: domains and DNS records, message log, credentials, webhooks. Signs in with an emailed magic link; first run bootstraps the admin WordPress-style.

These aren’t a code drop — the SMTP/IMAP edges are the same code serving MailKite production today, and the conformance suite that gates the repo runs against both backends.

One MX, many backends

The MX edge routes per recipient domain across multiple backends (docs/multi-backend.md): each backend claims its domains, RCPT checks consult every claim list, and accepted mail is signed and ingested to whichever backend owns the recipient. We run this in our own production — the same MX that fronts MailKite Cloud also delivers to a self-hosted backend. Which means you can skip running port 25 entirely and point our hosted MX at your self-hosted install.

Already running Haraka?

You don’t need to adopt the repo. The plugins are on npm as haraka-plugin-mailkite:

npm install haraka-plugin-mailkite
# config/plugins: add "mailkite"; config/mailkite.ini: role = mx  (or submit)

Your existing MX or submission server then speaks the contract to any backend — the bundled SQLite one, MailKite Cloud, or your own implementation.

Why open source it

Email infrastructure buyers are (rightly) lock-in-averse. The honest answer is to make the server open and keep the hosted product what it should be: deliverability, IP reputation, retention, webhooks at scale, and a human when something breaks. Self-host the parts that are yours; rent the parts that are genuinely hard to run — the SMARTHOST=cloud hybrid is exactly that split, one env var at a time.

If you’d rather not babysit port 25: the same web console connects to MailKite Cloud with one credential swap.

License

AGPL-3.0 for the code; the MailKite name and logo stay trademarked (forks rebrand). Contributions welcome — see CONTRIBUTING.md.