Sarolta engineering case study / mail operations
We turned tenant isolation into a product capability.
CompleteSender is the control plane we built when one SMTP deployment per customer stopped being operationally or economically credible.
The engineering constraint
A new customer used to mean a new MTA deployment.
Our solution Express tenant boundaries as application state and enforce them in the product—not as infrastructure recreated for every customer.
For a service provider, a customer is rarely just an SMTP credential. Enterprise accounts need boundaries around divisions, teams, users, senders, domains, IP pools, mailboxes, traffic policy, and audit.
The conventional answer is isolation by deployment: a server, container, or managed stack to provision, secure, patch, and observe. At scale, that deployment fleet becomes the system.
Model
Represent organisations, teams, roles, sender programmes, domains, IP pools, and mailboxes as explicitly scoped resources.
Operate
Keep DNS, signing, traffic policy, queues, delivery routes, logs, and message traces in the same operating model.
Guard
Apply traffic shaping, firewall controls, audit, notifications, and role-aware actions where they are evaluated.
Delegate
Expose scoped MCP or OpenAPI tools to authorised agents, with approvals and an audit trail.
The design move
Isolate resources and authority, not the deployment topology.
We built a multi-organisation control plane around a high-throughput delivery core. The product owns the tenant boundary, so operational resources can be scoped and checked without standing up another mail stack.
The operating model
From organisation setup to delivery control.
Tenant context is explicit
Organisations, teams, users, sender programmes, domains, IP pools, and mailboxes carry a defined operating boundary.
Mail operations live with the programme
DNS integration, authentication records, routing, queues, logs, and message traces are operated beside the sender they affect.
Policy is evaluated at the point of work
Traffic shaping, warm-up and rate controls, firewall controls, notifications, and role-aware actions protect delivery in context.
Automation receives bounded capability
MCP and OpenAPI tools are filtered by token, scope, approval, audit, rotation, revocation, and an account-level disable route.
What Sarolta built
A control plane where the account boundary is software.
Provisioning an organisation creates a bounded operational context, rather than another infrastructure project for a team to maintain.
One resource model
Platform operators manage organisations and customer users work only within the resources and actions they are authorised to control.
One delivery surface
Sender configuration, DNS, domain health, IP pools, queues, and delivery evidence stay connected instead of being scattered across deployments.
One authority model
Human and agent actions can be constrained, approved, audited, revoked, and disabled without breaking the tenant boundary.
The engineering surface
Keep ownership, delivery state, and intervention in the same model.
These illustrative views show how sender ownership, domain authentication, queue health, and agent activity remain connected to the organisation that owns them.
Sender operations
Programme status, delivery performance, domain health, ownership, and the next action remain in sender context.
Domain intelligence
DNS, authentication, alignment, reputation, and delivery signals become one diagnosable operational record.
Operations intelligence
Queue health, IP capacity, events, and scoped agent recommendations remain visible in the same accountable operating surface.
What changed
Provisioning became product state, not deployment work.
The delivery core is written in Rust. Around it, the product records resource ownership, authority, and operational evidence. Creating an organisation begins by defining its scoped resources and controls—not by planning a new LXC or Docker deployment.
1
organisation boundary, expressed through scoped resources and permissions rather than a dedicated deployment.
1
operating surface for sender programmes, DNS, IPs, traffic policy, queues, and delivery evidence.
2
agent integration paths: native MCP and generated OpenAPI tools for compatible AI platforms.
Agentic operations, with guardrails
We made delegation a controlled protocol.
Agents can help with operational work, but they do not receive ambient account authority. The control screen makes access level, allowed tools, token lifecycle, recent actions, approvals, and the disable route visible to the operator.
Engineering choices
Build the operating boundary into the system.
-
Tenant context before resource access
The account boundary, access level, and granular scopes are checked before a human, integration, or agent can use a tool or resource. -
Plans before high-impact execution
Plan hashes, approval, expiry windows, idempotency checks, and dangerous-action classification make consequential changes controllable. -
Observable, recoverable delegation
Audit, safe errors, rate limits, request visibility, token rotation and revocation, plus account-level disable controls make automation operable.