openclaw multi tenant email: how to isolate inboxes per agent and tenant

OpenClaw was built as a personal assistant. One user, one gateway, one set of credentials. That model works fine until you need three agents sharing a server, each signing up for different services, each needing its own email address that doesn't leak messages to the others.

Multi-tenant OpenClaw is where email gets messy. The default setup gives you a single email channel. Every agent on the gateway shares it. Verification codes land in the same inbox. Replies from different services pile up with no way to tell which agent triggered them. If agent A signs up for Notion and agent B signs up for Linear, both confirmation emails arrive in one undifferentiated stream. Now your agents are parsing each other's mail, or worse, acting on it.

This is the isolation problem, and most guides skip over it entirely.

How to set up email for multi-tenant OpenClaw (step-by-step)#

1. Provision a dedicated inbox for each tenant or agent using a programmatic email API like LobsterMail.
2. Store each inbox's credentials in an encrypted per-tenant vault, never in a shared environment variable.
3. Map each tenant's workspace block to its own email channel pointing at the dedicated inbox.
4. Configure inbound routing so replies and verification codes route to the correct agent's inbox by address.
5. Set allowedEmailDomains per tenant to restrict which domains each agent can send from.
6. Test isolation by sending a verification email from each agent and confirming no cross-delivery.
7. Monitor bounce rates and delivery logs per tenant to catch deliverability issues before they cascade.

That's the short version. The rest of this article explains why each step matters and what breaks when you skip one.

Why single-user email breaks at multi-tenant scale#

OpenClaw's default email channel is a single pipe. One SMTP connection, one inbox address, one polling loop. This works for a solo agent checking its own mail. It falls apart when you add a second tenant for two reasons.

Cross-contamination. Inbound emails have no tenant routing. If two agents share agent@yourdomain.com, a password reset intended for agent A's Slack signup could be read and acted on by agent B. This isn't hypothetical. The openclaw-multitenant repo from jomafilms exists specifically because people kept hitting this problem.

Credential leakage. Shared API keys mean a compromised agent exposes every tenant's email access. The Blink Blog's team deployment guide puts it clearly: "Each agent must have its own service account credentials. Never share API keys between agents." That advice applies double for email, where a leaked credential gives read access to every message in the shared inbox.

The fix isn't complicated. It's just tedious when done manually. Each tenant needs its own inbox, its own credentials, and its own routing rules.

Comparing your options for multi-tenant email#

There are three main approaches people use today. Each makes different tradeoffs.

Platform-owned SMTP#

You run your own mail server (Postfix, Haraka, or a managed provider) and configure OpenClaw to connect to it. You create mailboxes manually for each tenant.

This gives you full control. It also gives you full responsibility for DNS records, SPF/DKIM alignment, IP reputation, bounce handling, and inbox provisioning. For a three-tenant setup, this is manageable. For thirty tenants spinning up and down, you're now running a mail hosting company on the side.

AgentMail#

AgentMail is the most commonly referenced option in OpenClaw guides. Their blog post on OpenClaw integration walks through creating dedicated inboxes per agent. The setup involves signing up at their dashboard, creating an inbox, getting an API key, and wiring it into your OpenClaw config.

It works. The tradeoff is that inbox creation requires a human to visit a dashboard and copy credentials. That's fine for static deployments where tenants are provisioned once. It's a bottleneck when tenants come and go, or when an agent needs to spin up a temporary inbox for a single verification flow.

Agent-owned inboxes (LobsterMail)#

The third option is letting each agent provision its own inbox programmatically, with no human in the loop. This is what LobsterMail is built for. Your agent calls createSmartInbox() and gets a dedicated address in seconds:

import { LobsterMail } from '@lobsterkit/lobstermail';

const lm = await LobsterMail.create();
const inbox = await lm.createSmartInbox({ name: 'tenant-acme' });

console.log(inbox.address); // tenant-acme@lobstermail.ai

No dashboard visit. No manual credential copying. The SDK handles signup, token storage, and collision avoidance automatically. Each tenant's agent gets an isolated inbox that only it can read.

If you want to try this approach, grab an inbox for your agent here and paste the instructions into your OpenClaw skill.

Handling inbound routing without cross-contamination#

Outbound email is the easy part. Inbound is where multi-tenant setups break.

When your agent signs up for a service, the verification email comes back to whatever address was used. If all agents share one address, you need to parse the inbound message, figure out which agent triggered it, and route it correctly. Most teams try regex matching on subject lines or sender addresses. This is fragile and fails the moment a service sends a generic "Welcome!" email with no identifying context.

The cleaner solution: each agent uses its own unique address. Verification emails for tenant A go to tenant-a@lobstermail.ai. Emails for tenant B go to tenant-b@lobstermail.ai. No routing logic needed. Each agent polls its own inbox and only sees its own mail.

LobsterMail adds a security layer on top of this. Every inbound email gets an injection risk score, so your agent can flag suspicious messages before processing them. The security docs explain how the scoring works.

What about GoClaw and Clawith?#

Two projects worth mentioning if you're evaluating the multi-tenant space.

GoClaw is OpenClaw rebuilt in Go with native multi-tenant isolation and concurrency. It includes allowedEmailDomains configuration for restricting per-tenant email access. If you're already committed to running your own infrastructure and want tighter isolation at the gateway level, GoClaw is worth evaluating. It doesn't solve the inbox provisioning problem (you still need an email provider), but it gives you better guardrails around who can send from which domain.

Clawith extends OpenClaw with team workspaces and includes broadcast email capabilities. It's aimed at teams sharing a gateway, not at fully isolated multi-tenant deployments. The "lead waterfall" feature is more relevant to sales workflows than to infrastructure isolation.

Neither project provides the email inboxes themselves. They handle the gateway layer. You still need something (your own SMTP server, AgentMail, or LobsterMail) to actually receive and send mail.

The credential storage problem#

One thing every multi-tenant guide agrees on: never store email credentials in plaintext environment variables shared across tenants. The openclaw-multitenant repo uses an encrypted vault pattern where each tenant's secrets are encrypted at rest with a per-tenant key. If you're rolling your own setup, that's the minimum bar.

With agent-owned inboxes through LobsterMail, credential management simplifies. The SDK stores tokens at ~/.lobstermail/token per agent process. In containerized deployments where each tenant runs in its own container, this happens automatically with no shared state between tenants.

Picking the right approach#

If you're running a static deployment with two or three known tenants, platform-owned SMTP or AgentMail will work fine. The manual setup cost is low and you get full control.

If tenants are dynamic, if agents spin up and down, or if you need ephemeral inboxes for short-lived verification flows, agent-owned provisioning saves you from becoming a part-time email administrator. LobsterMail's free tier gives you 1,000 emails per month at no cost, which is enough to validate the pattern before committing.

The real question isn't which email provider to use. It's whether your agents should own their inboxes or whether a human should provision them. For multi-tenant OpenClaw, the answer depends on how often your tenant list changes.