---
title: "Multi-Tenant Email for SaaS Platforms: Giving Every Customer Their Own Inbox"
description: "How to architect multi-tenant email for SaaS platforms using workspaces. Isolated inboxes, scoped API keys, and billing separation — without building email infrastructure from scratch."
date: "2026-04-01"
author: "myagentmail"
tags: ["multi-tenant", "saas", "workspaces", "email-api", "architecture"]
image: "/blog-images/multi-tenant-email-saas-platforms.png"
---

# 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:

```typescript
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:

```typescript
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:

```typescript
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:**
1. Workspace created on sign-up
2. Client connects their domain (DNS records for SPF, DKIM, DMARC)
3. Sourcing agent inbox: `talent@clientdomain.com`
4. 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:**
1. Workspace per organization
2. Inboxes per channel: `support@`, `billing@`, `enterprise@`
3. 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:**
1. Workspace per company account
2. One inbox per sales rep: `sarah@company.com`, `mike@company.com`
3. 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.