A mailbox per customer (multi-tenant SaaS)

The governance model first

The isolation is the product here, so start with how it's enforced:

• Per-customer encryption key. Each customer's mailbox bodies and credentials are encrypted at rest with a dedicated Fernet key, itself master-wrapped. Credentials are never returned by any API or written to logs.
• Per-mailbox scoped keys. Each customer's agent holds an sm_live_… key scoped to exactly one mailbox, with a read / read_write role and an optional expiry. A leaked key reaches one tenant, never the fleet.
• Tenant-wide management key. An sm_mgmt_… key handles cross-mailbox operations across the mailboxes you own - issued from the dashboard, never agent-callable.
• Isolated suppression and limits. Bounce/complaint suppression and rate limits are tracked per mailbox, so one tenant's behavior never affects another's deliverability.
• Contained erasure. Destroying a customer's sub-key revokes that customer's keys and tears down their cached sessions, neutralizing access to their encrypted data - without touching any other tenant.

The problem: one shared inbox doesn't scale to many customers

A single mailbox shared across customers leaks data between tenants, makes per-customer revocation impossible, and turns one bad actor into everyone's problem. Building real isolation yourself means per-tenant mailboxes, per-tenant keys, per-tenant encryption, and suppression that doesn't bleed across accounts - plus an admin layer to manage it all. Sairaph Mail ships that model so you don't assemble it.

How it works

1. Provision a mailbox per customer. Create a mailbox for each end-customer on your managed domain as they onboard.
2. Scope a key to each mailbox. Issue a per-mailbox sm_live_… key with the role that customer's agent needs and an optional expiry; revoke one customer without touching the rest. Snippet: KEY_USAGE.
3. Keep tenants isolated. Each mailbox is encrypted per customer, and suppression and limits are isolated per mailbox.
4. Administer across the fleet. Use an sm_mgmt_ management key for tenant-wide operations spanning the mailboxes you own, while each customer's agent stays scoped to its own.
5. Grow without re-architecting. Add mailboxes as you add customers - the per-mailbox model is identical at one or many.

API / MCP touchpoints

• Per-tenant send/read: POST /api/v1/mailboxes/{mailbox_id}/outbound and GET /api/v1/mailboxes/{mailbox_id}/messages - each call carries a key scoped to one tenant's mailbox. Snippets: SEND_CURL, READ_INBOUND_CURL.
• Keys: per-mailbox sm_live_… (read / read_write) for each customer's agent; sm_mgmt_… for cross-mailbox ops. Dashboard-issued only - snippet KEY_USAGE.
• MCP: each customer's agent connects to /mcp/v1/mcp with its own scoped mailbox key, so the MCP tool surface is naturally tenant-isolated.

Why an owned, two-way mailbox per tenant beats the alternatives

A shared catch-all or a single transactional sender can't isolate one customer's mail from another's, can't be revoked per customer, and can't be encrypted per customer. A real mailbox per tenant gives you a hard isolation boundary - separate key, separate encryption, separate suppression - plus the two-way inbox each customer's agent needs, all governed from one tenant.

FAQ

How are customers isolated from each other? Each customer gets a separate mailbox with a dedicated per-customer encryption key and a key scoped to that single mailbox. Suppression and limits are tracked per mailbox, so tenants don't affect one another.

Can I revoke one customer without affecting others? Yes. Each per-mailbox key is independent - revoke or expire one and the rest keep working. Revocation takes effect almost immediately.

How do I manage many mailboxes at once? An sm_mgmt_ management key is tenant-wide and spans the mailboxes you own for cross-mailbox operations, while each customer's agent uses a key scoped to just its mailbox.

What happens to a customer's data when they leave? Destroying that customer's encryption sub-key revokes their keys and neutralizes access to their encrypted mailbox data, contained to that one customer.

How many mailboxes can I have? Mailbox allowances scale by plan. See pricing for the live per-plan figures, or talk to us for fleet volume.

Related

• Multi-tenant SaaS inboxes - the companion overview of the per-customer pattern.
• Provision an agent fleet - the agency angle: many clients, one tenant.
• Security - per-customer encryption, scoped keys, residency.

CTA: Talk to us - design per-customer isolation for your platform. Secondary: Get started.