iRedMail alternative.
Modern surface, real API.

At a glance

Side-by-side, current as of May 2026.

The verdict

How they differ

Deployment model

iRedMail's defining choice is OS-native. The installer script lays down Postfix, Dovecot, Roundcube, Nginx, Fail2ban, SpamAssassin, and (optionally) SOGo directly onto the host: no containers, no Docker daemon. That's a deliberate feature for sysadmin teams who prohibit container runtimes, run on BSD, or want the smallest possible runtime surface.

Vectis Mail ships as a Docker Compose stack: 14 services by default (10 if you disable observability and ClamAV). Each component is isolated, restartable independently, and version-pinned in a single compose.yml. If your environment prohibits Docker, that's a hard blocker for Vectis Mail; there's no OS-native install path planned. If Docker is acceptable, the trade-off is operational ergonomics: one command rebuilds the whole stack, and the orchestrator's update pipeline depends on container-level isolation.

API surface

iRedMail is a classic OS-native mail server. SMTP submission is the only programmatic interface for sending, and inbound mail lands in mailboxes only. There's no REST API for config, no domain-scoped API keys, no inbound webhooks, no per-domain rate limiting.

Vectis Mail has 40+ endpoints covering sending (single + batch with attachments), inbound webhooks (full body parsing, HMAC-signed payloads, exponential-backoff retry), mailbox/alias/domain CRUD, analytics, audit logs, and admin operations. Domain-scoped API keys with per-domain rate limits make it usable as a real transactional service: an in-house alternative to SendGrid or Postmark that happens to also host your mailboxes.

See the API Reference for the full surface.

Configuration model

iRedMail's configuration is what you'd expect from a long-running Unix mail server: files in /etc/postfix, /etc/dovecot, /etc/nginx, and so on. Adding a domain, rotating a DKIM key, or changing rate limits typically means editing files and restarting services, or clicking through the iRedAdmin web panel. There's no config-as-code surface.

Vectis Mail uses a single config.yaml as the source of truth. vectis apply diffs the desired state against running state, regenerates affected service configs (Postfix, Dovecot, Rspamd, Traefik), and reloads only what changed. The same operations are exposed via the REST API, so Terraform, Ansible, or your own automation can manage Vectis Mail declaratively.

Antispam

iRedMail ships with SpamAssassin by default. It's a workhorse, but materially weaker on modern spam patterns than Rspamd. Vectis Mail uses Rspamd by default, which gives you better default deliverability protection, modern heuristics (Bayes, fuzzy hashing, reputation), and a Lua extension surface for custom rules. If you want Rspamd on iRedMail, you can wire it in manually, but it's not the default.

Update + rollback

iRedMail updates are a documented manual procedure: package upgrades, file diffs, schema migrations applied by the operator. There's no automatic snapshot, no health-check gate, no rollback. If a migration breaks, recovery is whatever you do manually.

Vectis Mail's orchestrator runs a 6-phase pipeline:

1. Snapshot — Postgres dump + Compose backup taken before any change.
2. Migrate — forward-only SQL migrations applied with row-level locking.
3. Pull — new container images pulled and verified.
4. Deploy — services recreated with the new images.
5. Health-check — Postfix, Dovecot, Rspamd, API, Traefik all probed for liveness + actual mail-handling readiness.
6. Complete — change locked in, snapshot retained for the rollback window.

Any phase failure triggers automatic rollback to the snapshot. The Plan/Apply UI shows the diff before you run it. See Installation for the full update model.

Editions + pricing

iRedMail splits across three editions: iRedMail (open source), iRedMail Enterprise Edition (one-time per-server payment), and iRedAdmin-Pro (annual subscription with advanced web admin features). Pricing for the paid tiers isn't published publicly; you contact iRedMail for a quote.

Vectis Mail keeps it simple: Starter (free forever: up to 3 domains, 25 mailboxes per domain, full API, webhooks, monitoring, backups) and Pro at $29 USD/tenant/month (unlimited domains and mailboxes, per-domain analytics, OIDC SSO, priority support). One Pro subscription covers unlimited Vectis Mail installs operated by your organisation. See pricing.

Migrating from iRedMail to Vectis Mail

Because both products use Postfix and Dovecot under the hood, the mail data migrates cleanly. The typical sequence:

1. Stand up Vectis Mail on a fresh VPS following the installation guide. Configure your domain(s) but leave DNS pointed at iRedMail for now.
2. Sync mailbox data with imapsync or doveadm backup: both stacks are vanilla Dovecot underneath, so maildir transfers directly.
3. Generate new DKIM keys on Vectis Mail and publish them to DNS alongside the existing iRedMail keys. Run both in parallel during the switchover.
4. Export Sieve filters (per-user) from iRedMail Dovecot and import into Vectis Mail Dovecot (same file format).
5. Re-create domains, mailboxes, and aliases via the Vectis Mail CLI or API. If you're scripting this, the API + domain-scoped keys make it straightforward.
6. Export SOGo data (calendar / contacts) to iCal/vCard if you use it. Vectis Mail can't import these directly. This is the only non-trivial step.
7. If you're on OpenLDAP, you'll need to migrate user records from OpenLDAP into Vectis Mail's PostgreSQL-backed user store. There's no automated tool for this; it's a one-off script.
8. Cut DNS over: update MX to point at the Vectis Mail server. Mail starts flowing through Vectis Mail as DNS propagates.
9. Verify + decommission: watch logs for a few days, then decommission iRedMail.

Realistic timeline: half a day for a small (<50 mailbox) MySQL/MariaDB-backed install, a few days of staged migration for larger installs or anything backed by OpenLDAP.

Frequently asked questions