Skip to content
MIRNINTMail

Platform

Two planes, one system of record

Mirnint Mail separates the control plane — API, dashboard, verification, metadata — from the mail-delivery plane that renders, signs and moves messages. Each is a distinct security and failure domain.

Control plane

  • mmail-apiPublic REST API: sending, domains, keys, templates, webhooks
  • mmail-webDashboard: logs, domain health, templates, suppressions, operations
  • mmail-domain-verifierMulti-resolver DNS verification with recorded observations
  • mmail-webhook-dispatcherSigned, retried, SSRF-guarded event delivery

Mail-delivery plane

  • mmail-workerRendering, MIME generation and authenticated MTA submission
  • Postfix outbound nodesDedicated VMs, clean static IPs, persistent queues
  • RspamdDKIM signing and outbound policy enforcement at the edge
  • mmail-mta-event-agentPostfix log parsing into idempotent lifecycle events
  • Inbound bounce MXDSN and feedback-loop ingestion on separate nodes

The public API never runs on the outbound MTA IP addresses, and the MTA fleet never trusts client-supplied metadata: signing decisions resolve from verified domain mappings, not headers.

Foundations

Built on components you can operate

Boring, proven infrastructure — deployed with automation, observed end to end, backed up and restore-tested.

  • PostgreSQL

    The authoritative system of record — queues are transport, not truth

  • Transactional outbox

    No job is ever lost between a database commit and the queue

  • RabbitMQ

    Durable quorum queues with publisher confirms and idempotent consumers

  • Redis

    Distributed rate limiting and fast counters

  • MinIO

    Object storage for content and scanned attachments

  • Vault

    DKIM private keys, API-key pepper and service credentials

  • OpenTelemetry stack

    Prometheus metrics, Loki logs and end-to-end traces

  • Kubernetes + dedicated VMs

    Control plane on K8s; MTA nodes on hardened Linux VMs

Multi-tenancy

Organizations, projects and real isolation

Every domain, key, template, message and webhook belongs to exactly one organization. Projects isolate environments — production, staging, development — with their own keys, quotas and logs.

Identity resolved server-side

API keys resolve to their organization and project. A client-supplied tenant ID is never trusted.

Recipient-level truth

Five recipients means five tracked delivery states. Aggregate status is derived, never overwritten.

Quota and abuse controls

Independent limits per key, project, organization, domain, recipient and IP pool — with automatic protective actions that are audited and reversible.