The Mail-in-a-Box alternative
built for production.

At a glance

Side-by-side, checked against Mail-in-a-Box's README in October 2026.

Why teams move to Vectis Mail

Where a one-command personal box stops being enough.

One honest scope note: Vectis Mail doesn't yet ship bundled CalDAV/CardDAV calendar and contacts (it's on the Phase 4 roadmap). If groupware calendar/contacts are central to your daily use, factor that gap into your plan — pair Vectis Mail with a dedicated CalDAV/CardDAV service for that lane.

How they differ

Different products for different audiences

Mail-in-a-Box's README is explicit: "no user-configurable setup options."That's the value proposition. The project deliberately optimises for a one-command personal email box over flexibility — a deliberately narrow scope. Vectis Mail is built for the wider job: production infrastructure you can operate, automate, and scale across domains and teams.

Vectis Mail sits in a different category. The audience is teams, SaaS, and multi-domain operators who need a real transactional sending API, inbound webhooks, multi-domain hosting, and config-as-code. Comparing the two on the same table is useful for the migration question, but understand what each product is for.

API surface

Mail-in-a-Box exposes a minimal REST API for control-panel operations: creating users, managing aliases, setting forwards. There's no transactional sending API, no inbound webhooks, no domain-scoped keys, no per-domain rate limiting. SMTP submission is the only programmatic send path.

That matters the day an application, not a person, needs to send. On Mail-in-a-Box your app logs in over SMTP with a real mailbox's password, so every service that sends mail holds a user credential, and a leaked one opens the whole mailbox. On Vectis Mail each app gets its own API key, scoped to the domains it may send from and with its own rate limit, and it posts JSON (single or batch, with attachments) instead of speaking SMTP. Replies and inbound mail can come back to your app as HMAC-signed webhooks with retry, which Mail-in-a-Box has no equivalent for. In all, 40+ REST endpoints, also covering mailboxes, aliases, domains, analytics and audit logs.

See the API Reference for the full surface.

Multi-domain hosting

Mail-in-a-Box is single-org-shaped. You can run multiple domains on one box, but the control panel, the user model, and the operational shape all assume one organisation. Vectis Mail hosts many domains on one install, each isolated at the domain level — its own DKIM keys, analytics, and spam controls. If you're running mail for multiple brands or customer subdomains, that's a structural difference, not a config tweak.

Configuration model

Mail-in-a-Box's configuration lives in the web control panel and on-disk files managed by the install script. There's no declarative config surface. Every change is a UI click or a manual file edit, and the upgrade path documented as "fresh OS only"means modifying the box voids the supported upgrade story.

Vectis Mail takes the opposite position to "no user-configurable setup options", without asking you to hand-edit Postfix. Day-to-day changes (domains, mailboxes, aliases, API keys) happen in the admin dashboard or over the API and apply at once. The settings Mail-in-a-Box won't let you touch, such as spam thresholds, which services run and resource limits, sit in one file the installer writes for you, and vectis config apply shows the diff, then regenerates and reloads only the services that changed. Settings made this way are carried through every update rather than fighting it.

Update + rollback

Mail-in-a-Box upgrades by re-running the setup script: straightforward when the box is unmodified, fragile when you've customised anything. There's no automatic snapshot, no health-check gate, no rollback. If a release breaks something, recovery is whatever you do manually.

On Vectis Mail an update is one command, vectis update apply, and it is the same whether or not you've customised the box. It snapshots the database and stack first, pulls the new release's images (verified against a signed manifest), recreates the services, and checks that Postfix, Dovecot, Rspamd and the API are all answering before it calls the update done. If any step fails, it restores the snapshot on its own. You never find out mid-upgrade that a hand edit broke the setup script, and vectis verify confirms afterwards that the box runs exactly the published release. SeeInstallation for the full update model.

Calendar + contacts

Mail-in-a-Box bundles Nextcloud for CalDAV and CardDAV; calendar and contacts work out of the box. Vectis Mail doesn't ship calendar/contacts yet; that's on the Phase 4 roadmap. If you actively use CalDAV/CardDAV, that's our most significant functional gap today — plan to pair Vectis Mail with a separate CalDAV/CardDAV service until Phase 4 lands.

License + pricing

Mail-in-a-Box is CC0-1.0: public domain, the most permissive license possible. Zero lock-in, zero strings, no commercial edition, no paid support, donations welcome.

Vectis Mail is dual-licensed: BSL 1.1 for the core (free Starter: up to 3 domains, 25 mailboxes per domain, full API, webhooks, monitoring, backups) and a commercial Pro license at $39 USD/tenant/month (unlimited domains and mailboxes, per-domain analytics, OIDC SSO, priority support, one subscription covers unlimited installs). Seepricing.

Migrating from Mail-in-a-Box to Vectis Mail

The mail-data layer migrates cleanly (both products are vanilla Postfix + Dovecot). The calendar/contacts and control-panel-config layers need manual export.

1. Check who serves your DNS. Mail-in-a-Box runs its own DNS server (nsd4) and many boxes are their domain's nameserver. If yours is, move DNS hosting to your registrar or a DNS provider first, copying every record across, because the old box is about to go away.
2. Take a final Mail-in-a-Box backup (its built-in duplicity backup), so you have a restore point that doesn't depend on the migration.
3. Stand up Vectis Mail on a fresh Ubuntu 24.04 VPS with the installation guide, add your domains, and leave MX pointing at Mail-in-a-Box for now.
4. Copy the mailboxes with imapsync or doveadm backup. Both products use Dovecot, so folders and flags come across intact.
5. Publish Vectis Mail's DKIM key next to the existing one. Mail-in-a-Box signs with the selector mail and Vectis Mail with default, so both keys stay valid through the switchover.
6. Export Roundcube settings (per-user filters, signatures) from Mail-in-a-Box Roundcube and re-import into Vectis Mail Roundcube.
7. Re-create domains, mailboxes, aliases, and forwards via Vectis Mail's CLI or API. The Mail-in-a-Box control panel doesn't export config-as-code, so this is a manual transcription.
8. Export Nextcloud calendar + contacts to iCal/vCard if you use them. Vectis Mail can't import these — you'll need a separate CalDAV/CardDAV destination from this point. This is the most significant step if calendar is part of your daily use.
9. Switch MX and SPF to the Vectis Mail server, run a final imapsync pass for anything that arrived meanwhile, and point mail clients at the new host.
10. Keep the old box for a week, read-only, then switch it off once mail has been flowing cleanly through the new server.

Realistic timeline: an afternoon for a small personal install without calendar, longer if Nextcloud calendar/contacts are central to your use.

Frequently asked questions