2026-04-01 · multi-tenant saas workspaces email-api architecture

Multi-Tenant Email for SaaS Platforms: Giving Every Customer Their Own Inbox

You're building a SaaS platform and your customers need email. Not "send a notification" email — real inboxes that their agents or workflows can use to send, receive, and manage conversations.

Maybe you're building a recruiting platform where each client's sourcing agent needs its own email address. Or a customer support tool where each team gets dedicated inboxes. Or a sales automation platform where each user's outreach agent sends from a personalized address.

The common thread: you need to provision email per customer, isolate their data, scope their access, and ideally not build an email platform from scratch.

The Multi-Tenancy Problem

Multi-tenant email is deceptively hard. The naive approach — creating inboxes on a shared account and filtering by address — breaks down quickly:

No isolation. A misconfigured API call from one customer could read another customer's mail. A compromised credential exposes everyone.

No scoped access. If you give a customer an API key, they can access all inboxes, not just their own. You end up building an authorization layer on top of the email API.

No billing separation. You can't track which customer is consuming what. You're eating the cost of high-volume customers and can't implement per-customer rate limits.

No independent domains. All customers share your domain's sender reputation. One customer sending spam destroys deliverability for everyone.

The Workspace Model

The solution is workspaces — hard boundaries between tenants at the infrastructure level. Here's how this maps to a typical SaaS architecture:

Your SaaS Platform
├── Customer A (workspace-a)
│   ├── API Key: key_a_xxxxx (can only access workspace-a)
│   ├── Inbox: sourcing@customera.com
│   ├── Inbox: outreach@customera.com
│   └── Domain: customera.com
├── Customer B (workspace-b)
│   ├── API Key: key_b_xxxxx (can only access workspace-b)
│   ├── Inbox: support@customerb.com
│   └── Domain: customerb.com
└── Customer C (workspace-c)
    ├── API Key: key_c_xxxxx (can only access workspace-c)
    ├── Inbox: sales@customerc.com
    └── Domain: customerc.com

Each workspace is isolated. API keys are scoped to a single workspace. Domains and sender reputation are independent. Billing is tracked per workspace.

Implementation

Provisioning a New Customer

When a new customer signs up for your platform, you create a workspace and generate a scoped API key:

async function provisionCustomer(customerName: string) {
  // Create a workspace for the customer
  const workspace = await fetch("https://myagentmail.com/v1/workspaces", {
    method: "POST",
    headers: {
      "X-API-Key": process.env.MYAGENTMAIL_ADMIN_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      name: customerName,
    }),
  }).then((r) => r.json());

  // Generate a scoped API key for this workspace
  const apiKey = await fetch(
    `https://myagentmail.com/v1/workspaces/${workspace.id}/api-keys`,
    {
      method: "POST",
      headers: {
        "X-API-Key": process.env.MYAGENTMAIL_ADMIN_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        name: `${customerName} production key`,
      }),
    }
  ).then((r) => r.json());

  return {
    workspaceId: workspace.id,
    apiKey: apiKey.key,
  };
}

Creating Inboxes per Customer

Each customer can have multiple inboxes — one per agent, one per team, one per workflow:

async function createInboxForCustomer(
  workspaceApiKey: string,
  username: string,
  domain: string,
  displayName: string
) {
  const inbox = await fetch("https://myagentmail.com/v1/inboxes", {
    method: "POST",
    headers: {
      "X-API-Key": workspaceApiKey,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      username,
      domain,
      displayName,
    }),
  }).then((r) => r.json());

  return inbox;
}

// Create inboxes for a recruiting platform customer
await createInboxForCustomer(
  customerApiKey,
  "sourcing",
  "techcorp.com",
  "Alex — TechCorp Recruiting"
);

await createInboxForCustomer(
  customerApiKey,
  "outreach",
  "techcorp.com",
  "Jordan — TechCorp Talent"
);

Handling Inbound Mail per Tenant

When your customer's agent receives mail, you need to route it to the right handler. With WebSockets, each workspace gets its own connection:

function listenForCustomerMail(workspaceApiKey: string, workspaceId: string) {
  const ws = new WebSocket(
    `wss://myagentmail.com/v1/ws?workspaceId=${workspaceId}`,
    { headers: { "X-API-Key": workspaceApiKey } }
  );

  ws.on("message", (raw) => {
    const event = JSON.parse(raw.toString());

    if (event.type === "message.received") {
      // Route to the correct agent/handler based on inbox
      handleInboundEmail(workspaceId, event.data);
    }
  });

  return ws;
}

Use Case: Recruiting Platform

A recruiting SaaS where each client company gets AI sourcing agents.

Setup per client:

Workspace created on sign-up
Client connects their domain (DNS records for SPF, DKIM, DMARC)
Sourcing agent inbox: talent@clientdomain.com
Each open role can get its own inbox: swe-senior@clientdomain.com

How it works:

The sourcing agent sends personalized outreach to candidates from the role-specific inbox
Candidates reply directly to that address
The agent receives the reply in real time, processes it, and responds or escalates
All conversations are isolated to the client's workspace — no cross-contamination

Use Case: Customer Support Platform

A support SaaS where each team gets dedicated support inboxes.

Setup per team:

Workspace per organization
Inboxes per channel: support@, billing@, enterprise@
Custom domain for brand consistency

How it works:

Customers email support@clientdomain.com
The AI agent triages, responds to simple queries, and escalates complex ones
Each response comes from the same branded address
Different teams within the org can have their own inboxes without seeing each other's mail

Use Case: Sales Automation Platform

A sales tool where each rep gets their own outreach agent.

Setup per company:

Workspace per company account
One inbox per sales rep: sarah@company.com, mike@company.com
Sender reputation builds independently per rep

How it works:

Each rep's agent sends outreach from their personal inbox
Replies are received and triaged by the agent
Positive responses are routed to the human rep
Follow-up sequences continue automatically
One rep's aggressive outreach doesn't affect another's deliverability

What You Don't Have to Build

Without a workspace-based email API, implementing multi-tenant email means building:

An inbox abstraction layer on top of raw SMTP/IMAP
An authorization system to scope access per customer
A credential management system for per-customer API keys
A domain management system with DNS verification
A routing layer for inbound mail
A billing tracking system per tenant
An isolation layer to prevent data leakage

That's six months of infrastructure work before you write a single line of your actual product. With workspace-scoped email, you get all of this out of the box and can focus on what makes your platform unique.

The platform you're building solves a problem for your customers. Email is plumbing. Use plumbing that was built for multi-tenant use cases so you can ship the features that actually differentiate your product.