Running one OpenClaw agent with email is straightforward. Running five agents across three tenants, each with its own inbox, sender reputation, and inbound routing? That's where things get interesting.

Multi-tenant OpenClaw deployments are becoming common. The openclaw-multitenant project on GitHub already offers container isolation and encrypted vaults. Blink's team guide documents five specialized agents running for about $110/month. And a feature request for native multi-tenant gateway support has been gaining traction since early 2026.

But email configuration across tenants remains the messiest part of the setup. Most guides cover workspace directories and channel accounts, then handwave past the email piece with "configure SMTP in your .env." That's not enough when you need tenant isolation, deliverability protection, and inbound reply routing.

This guide covers the full picture.

How to configure multi-tenant email in OpenClaw (step-by-step)#

1. Create a separate workspace directory for each tenant (e.g., ~/.openclaw/workspace-tenant-a).
2. Set per-tenant SMTP credentials in each tenant's .env file or secrets vault entry.
3. Configure distinct FROM addresses per tenant to avoid cross-tenant reputation bleed.
4. Set up inbound email routing so replies land in the correct tenant's conversation thread.
5. Apply per-tenant sending limits to prevent one agent from exhausting shared quotas.
6. Store all email credentials in OpenClaw's encrypted vault with per-tenant access scoping.
7. Test each tenant's authentication (SPF, DKIM, DMARC) independently before going live.

That's the overview. Now let's dig into each piece and the trade-offs involved.

Tenant isolation: workspaces vs. email accounts#

OpenClaw's multi-tenant model isolates tenants at the workspace level. Each tenant gets its own agentDir, state files, and channel configurations. The openclaw-multitenant project adds container-level isolation on top of this, so one tenant's processes can't read another tenant's memory.

But workspace isolation and email account isolation are two different things. You can run five tenants in five containers and still have them all sending through the same Gmail OAuth token. That's a problem. If tenant A's agent sends 400 messages and triggers a spam flag, tenant B's agent loses sending privileges too. Shared credentials mean shared consequences.

The fix is straightforward in theory: give each tenant its own email account. In practice, this means managing N sets of OAuth tokens (for Gmail or Outlook) or N sets of SMTP credentials, plus the DNS records to authenticate each sender.

The SMTP approach#

SMTP is the most common setup for self-hosted OpenClaw. Each tenant gets its own credentials in its .env file:

Tenant A#

SMTP_HOST=smtp.example.com SMTP_PORT=587 SMTP_USER=tenant-a@yourdomain.com SMTP_PASS=app-specific-password-here

Tenant B#

SMTP_HOST=smtp.example.com SMTP_PORT=587 SMTP_USER=tenant-b@yourdomain.com SMTP_PASS=different-password-here This works. But it comes with maintenance overhead that scales linearly. Every new tenant means new credentials, new DNS records (SPF includes, DKIM selectors), and new monitoring for bounce rates and complaint ratios.

For Gmail, each tenant needs its own OAuth consent flow with the gmail.send and gmail.readonly scopes. For Outlook/Exchange, you need Mail.Send and Mail.ReadWrite permissions per tenant. Rotating these credentials without downtime requires updating the encrypted vault entry and reloading the tenant's gateway process, which the openclaw-multitenant project supports through its hot-reload mechanism but the vanilla OpenClaw gateway does not.

Deliverability in multi-tenant setups#

This is the part most guides skip entirely. Deliverability isn't just "did the email leave the server." It's whether the email arrived in the recipient's primary inbox, and in a multi-tenant deployment, one tenant can poison the well for everyone.

Three things matter here:

Sender reputation is per-domain, not per-account. If tenants share a sending domain (e.g., tenant-a@yourcompany.com and tenant-b@yourcompany.com), their reputation is pooled. Tenant A's aggressive outreach tanks tenant B's transactional emails. The only real fix is dedicated sending domains per tenant, which means dedicated SPF, DKIM, and DMARC records per domain.

Warm-up can't be parallelized naively. Each new sending domain or IP needs gradual volume increases over 2-4 weeks. Spinning up 10 tenants simultaneously and having each send 100 emails on day one will trigger rate limiting or blocklisting at most major providers.

Bounce handling needs per-tenant tracking. A 5% bounce rate on tenant C shouldn't affect tenant D's sending. But if your bounce processing is centralized, you might not catch which tenant is generating the bad addresses until the domain-level reputation is already damaged.

Inbound email: routing replies to the right tenant#

Sending is half the problem. The other half is receiving. When someone replies to an email sent by tenant A's agent, that reply needs to land in tenant A's conversation thread, not in a shared inbox where tenant B's agent might read it.

OpenClaw doesn't have built-in inbound email routing for multi-tenant setups. The common approaches are:

Unique reply-to addresses per tenant. Set each tenant's outbound Reply-To header to a tenant-specific address. Then use a mail server or webhook to route incoming mail based on the recipient address. This works but requires either a catch-all inbox with parsing logic or per-tenant MX records.

Webhook-based routing. If your email provider supports inbound webhooks (Mailgun, Postmark, and others do), you can set up a webhook endpoint that inspects the To address or a custom header, then forwards the payload to the correct tenant's gateway. This is cleaner than polling but adds another moving part.

Shared mailbox with thread parsing. Use a single inbox like agents@yourdomain.com and parse the In-Reply-To or References headers to match replies to the originating tenant. Technically feasible, but fragile. Header threading breaks with some email clients, and you're one misconfigured rule away from cross-tenant data leakage.

The agent-first alternative#

All of the above assumes you're wiring email infrastructure yourself. There's a different model where the agent handles its own email provisioning, and multi-tenancy becomes a non-issue because each agent (or tenant) gets an isolated inbox by default.

LobsterMail takes this approach. Instead of configuring SMTP credentials per tenant, each agent creates its own inbox programmatically:

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

const lm = await LobsterMail.create();
const inbox = await lm.createSmartInbox({ name: 'Tenant A Agent' });
// tenant-a-agent@lobstermail.ai — isolated, no shared credentials

No .env files per tenant. No OAuth token rotation. No shared sender reputation. Each inbox is independent, with its own address and its own deliverability profile. Inbound replies route to the inbox that sent the original message, so multi-threaded conversations stay isolated without webhook plumbing.

The free tier includes 1,000 emails per month. The Builder tier ($9/month) covers up to 10 inboxes with 5,000 emails per month, which fits most multi-agent team setups. If you want to try it, get your agent its own inbox here and paste the instructions to your agent.

Comparing the approaches#

None of these options is universally best. If you're already running Google Workspace with five seats, OAuth might be the simplest path. If you need full control over your mail server, self-managed SMTP gives you that. If you want the agent to handle email without human involvement, the programmatic approach removes the most friction.

Credential security in the vault#

Whatever backend you choose, storing email credentials securely matters. OpenClaw's encrypted vault (introduced in the openclaw-multitenant project) encrypts secrets at rest with a per-tenant key. But "encrypted at rest" doesn't cover every threat model.

A few things to watch: vault access should be scoped per tenant so that tenant A's gateway process can't decrypt tenant B's SMTP password. The decryption key itself needs to live outside the container (environment variable injection at startup, not baked into the image). And credential rotation should be possible without restarting the entire gateway, which currently requires the hot-reload feature from the multi-tenant fork.

For HeraClaw Cloud (the managed OpenClaw hosting), email credential management depends on which channels you've configured. The documentation is sparse on multi-tenant email specifically, so expect some manual setup even on the managed platform.

Where things are headed#

The GitHub feature request for native multi-tenant gateway support (#61123) suggests that OpenClaw will eventually handle tenant isolation at the framework level rather than requiring a separate project fork. When that lands, email configuration per tenant should become a first-class concept rather than a bolted-on pattern.

Until then, the choice is between managing the complexity yourself or letting each agent provision its own email. I'd lean toward the latter for new deployments, and keep self-managed SMTP for cases where you need specific sending domains or regulatory control over the mail server.