How can I provision an email inbox for every customer of my SaaS?

Use multi-tenant email infrastructure with programmatic provisioning: with Mektup, your backend makes one API call per tenant to create a real, isolated mailbox (e.g. acme@yourapp.com) under your single account. Mailboxes are unlimited, receiving is unmetered, and each mailbox has its own webhook so your app reacts to every tenant's mail instantly.

How do I keep one customer from seeing another customer's email?

Don't build the isolation yourself - use infrastructure that enforces it. Mektup scopes access per mailbox: a tenant sees only their own inbox, never your account, your other domains, or other tenants' mail, while your application keeps controlled API access to all of them.

How to Give Every Customer of Your SaaS Their Own Email Inbox

The pattern: tenant → mailbox

The product experience you're after looks like this: a customer signs up for your app and gets acme@yourapp.com (or an address on their own domain) - a real inbox that receives mail from anyone, that your app can display, and that your automation or AI can act on. Multiply by every tenant.

Your SaaS
   │  one API call per new customer
   ▼
customer-a@yourapp.com   ← Customer A (and only A)
customer-b@yourapp.com   ← Customer B (and only B)
customer-c@yourapp.com   ← Customer C + their AI agent

The managed way: provision over an API

Mektup is multi-tenant email infrastructure: your backend creates a real, isolated mailbox per customer through one API (or MCP) call, under your single account and key.

# new tenant signs up -> give them an inbox
curl -X POST "https://api.usemektup.com/v1/domains/yourapp.com/mailboxes" \
  -H "Authorization: Bearer mek_live_..." \
  -H "Content-Type: application/json" \
  -d '{"localPart": "acme"}'

# acme@yourapp.com now receives real mail from anyone.
# Wire a webhook and your app hears about every message instantly.

Mailboxes are unlimited, and receiving is unmetered - only outbound sending counts against the plan - so a large fleet of mostly-receiving tenant inboxes stays cheap.

The isolation requirements that actually matter

A tenant sees only their own mailbox - never your account, your other domains, or another tenant's mail. With Mektup, scoped access is granted per mailbox and enforced by the platform, not by WHERE clauses you have to get right in every query.
Your app keeps controlled access to all of them - it provisions, reads, and sends via the API; per-customer logins for the humans are scoped to exactly one mailbox (Enterprise tier).
Per-tenant automation stays per-tenant - each mailbox has its own webhook, so a customer's AI agent reacts only to that customer's mail. See multi-tenant email for the full model.

Where AI agents fit

Because every mailbox is API/MCP-operable and webhook-driven, "each customer gets an inbox" upgrades naturally to "each customer gets an inbox with an AI agent working it" - reading, triaging, drafting, replying - while the customer watches the same mailbox from your UI or their mail client. There's a complete open-source example of the agent loop: mektup-inbox-agent.

Shipping checklist

Register your product domain in Mektup, add the DNS records once.
On tenant signup: POST /v1/domains/:domain/mailboxes with the tenant's slug.
Set the mailbox webhook to your app's endpoint; store the signing secret per tenant.
Render the inbox in your product via GET /v1/messages?mailbox=..., or hand the customer scoped credentials.
On tenant offboarding: delete the mailbox - one call.

Get started free

How to give every SaaS customer their own email inbox