openclaw multitenant email: how to give every agent its own inbox

If you're running OpenClaw in a multi-tenant setup, you've probably hit the email wall. One agent needs to verify an account. Another needs to reply to a customer. A third is monitoring a shared inbox that two other agents also read from. And somewhere in the middle, Gmail has quietly locked your OAuth token because Google decided your agent's behavior looked "suspicious."

The email problem in multi-tenant OpenClaw isn't whether agents can send and receive. They can. The problem is isolation. When multiple agents share credentials, read the same mailbox, or send through the same gateway, things break in ways that are hard to debug and expensive to fix.

I've been watching the openclaw-multitenant fork gain traction over the past few months. It solves container isolation, encrypted vaults, and team sharing. But email? That's still mostly left as an exercise for the deployer. Let's fill in the gap.

What "multi-tenant email" actually means for OpenClaw#

In a standard single-agent OpenClaw setup, email is simple. You connect one Gmail account or one IMAP mailbox, and the agent uses it. Fine.

Multi-tenant changes the equation. You have multiple agents (or multiple users running agents) on the same infrastructure. Each tenant needs:

• A dedicated inbox that other tenants can't read
• A sending identity that doesn't share reputation with other tenants
• Credentials stored separately so a compromised agent doesn't expose everyone's email
• The ability to spin up and tear down inboxes as tenants are added or removed

The jomafilms/openclaw-multitenant fork handles the first part well. Container isolation keeps agents sandboxed. The encrypted vault stores secrets per tenant. But the vault only protects credentials at rest. It doesn't solve the upstream problem of where those credentials come from or how to manage dozens of inboxes without manually provisioning each one.

Why Gmail breaks at multi-tenant scale#

The most common setup I see in the wild: every tenant connects their personal Gmail via OAuth. This works until it doesn't. And it stops working fast.

Google's abuse detection flags automated access patterns. An agent that checks for new mail every 30 seconds, parses every message programmatically, and sends replies with near-zero delay looks nothing like a human user. Multiply that by 10 tenants on the same IP, and Google's systems start asking questions.

The r/AiForSmallBusiness guide recommends Gmail as the default, but even that thread's comments are full of people reporting disabled accounts within weeks. The fix is always the same: stop using personal email accounts for agent automation.

There's also a subtler issue. Gmail's sending limits are per-account, not per-application. If tenant A's agent sends 400 emails and tenant B's agent tries to send 200, they're not competing with each other (different accounts). But if you're using a shared workspace Gmail, they absolutely are. And you won't know you've hit the limit until messages start bouncing.

Setting up email for OpenClaw multi-tenant#

Here's the approach that actually scales. Whether you use LobsterMail, self-hosted IMAP, or another provider, the architecture should follow these steps:

1. Provision one dedicated inbox per tenant at enrollment time
2. Store the inbox credentials in the tenant's encrypted vault partition
3. Configure the agent's sending identity to match its dedicated address
4. Set up inbound routing so replies land in the correct tenant inbox
5. Automate inbox suspension when a tenant is paused or a container stops
6. Tear down the inbox and purge stored credentials when a tenant is offboarded
7. Audit sent messages per tenant using unique sender addresses

The key principle: treat inboxes as part of the tenant lifecycle. When a tenant is created, an inbox is created. When a tenant is paused, the inbox stops accepting outbound. When a tenant is deleted, the inbox is deleted. No orphaned mailboxes, no credential leaks.

The self-hosted IMAP approach (and its costs)#

You can absolutely run your own mail server. Postfix, Dovecot, and a DNS setup with SPF, DKIM, and DMARC records will give you full control. For teams with ops experience, this is a legitimate option.

But the operational cost is real. You're managing DNS records per domain, monitoring sender reputation, handling bounce processing, rotating DKIM keys, and keeping the server patched. For 3 agents, that's manageable. For 30 tenants, you've accidentally built an email hosting company.

I talked to a team running 22 OpenClaw agents on a self-hosted Postfix stack. Their ops engineer spends roughly 8 hours a month on email maintenance alone. Domain warm-up for new tenants takes 2-3 weeks before deliverability stabilizes. And when one tenant's agent sent a batch of poorly formatted emails that triggered spam complaints, the shared IP's reputation dragged everyone else's deliverability down with it.

That last point is worth emphasizing. Shared IP reputation is the silent killer of multi-tenant email. Unless you're assigning dedicated IPs per tenant (which most self-hosted setups don't), one bad actor poisons the well for everyone.

Where agent-first email fits in#

This is where the architecture philosophy matters more than any specific vendor. Traditional email services were built for humans who create accounts, configure settings, and manually manage their inbox. Agent-first email flips this: the agent provisions its own inbox programmatically, no human signup required.

For multi-tenant OpenClaw, that means your orchestration layer can create an inbox the moment it spins up a new tenant container, without filing a support ticket or clicking through a dashboard. And it can tear that inbox down just as quickly.

LobsterMail was built for exactly this pattern. Your agent calls createSmartInbox() and gets a dedicated address in seconds. No DNS configuration, no SMTP credentials to rotate, no warm-up period. Each inbox is isolated by default, so tenant A's agent can never read tenant B's mail, and each tenant's sending reputation is independent.

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

That's the entire provisioning step. No vault configuration, no DNS records, no OAuth dance. The agent handles it.

For inbound mail, inbox.receive() returns messages with built-in injection risk scoring, which matters in multi-tenant setups where agents process email from untrusted sources. A compromised inbound message that tricks one agent into leaking data is bad. One that tricks an agent into leaking another tenant's data is catastrophic.

Security boundaries you should actually think about#

The openclaw-multitenant fork's container isolation is solid for compute. Each agent runs in its own container, with its own filesystem and process space. But email adds attack surface that containers alone don't cover.

Consider these scenarios:

Credential leakage between tenants. If all agents use the same SMTP relay with different "From" addresses but the same authentication credentials, a compromised agent can send email as any tenant. Per-tenant credentials (or per-tenant inboxes with no shared credentials) eliminate this.

Inbound email poisoning. An attacker sends a carefully crafted email to tenant A's inbox containing instructions designed to manipulate the agent. In a shared-mailbox setup, this email might be visible to other tenants' agents too. Dedicated inboxes with per-tenant filtering prevent cross-contamination.

Audit trail gaps. When something goes wrong, you need to answer "which agent sent this email?" If all agents send through the same gateway with the same credentials, your logs show one sender. Unique per-tenant addresses make every message traceable.

The free tier of LobsterMail gives you isolated inboxes with 1,000 emails per month at no cost. For teams testing multi-tenant setups, that's enough to validate the architecture before committing to the Builder plan at $9/month for higher volume.

A practical comparison#

The right choice depends on your scale and ops appetite. If you're running 2-3 agents and you enjoy managing mail servers, self-hosted works. If you're building a platform where tenants come and go, programmatic provisioning saves real time.

What happens when an agent is paused?#

This question comes up often with openclaw-multitenant. When a container is stopped, the agent can't poll for new mail. But mail doesn't stop arriving.

With self-hosted IMAP, messages queue on the server until the agent resumes. Storage fills up if the pause is long. With Gmail, messages sit in the inbox, but OAuth tokens may expire during extended pauses, requiring re-authentication.

With LobsterMail, inbound mail is stored and available whenever the agent resumes polling. No token expiration, no storage limits on the free tier beyond the monthly email cap. The inbox persists independently of the agent's runtime state.

If you want your agents to handle email without the provisioning headaches, set up LobsterMail here and paste the instructions to your agent. It takes about 30 seconds.