Email control plane for Slack-based agents

Turn slash commands and workflow automations into governed email actions. MultiMail's approval queue means a chat message never becomes an unreviewed outbound email.

Slack is where agents and humans already collaborate — so it's a natural place to trigger email actions. A sales bot summarizes an inbox thread on demand. A support workflow routes inbound emails to the right channel. A scheduled bot drafts and queues outbound messages for human review. These patterns all work, but they require a layer between the chat command and the SMTP relay.

MultiMail sits at that layer. When a Slack bot calls `send_email`, the request enters MultiMail's oversight pipeline rather than going directly to delivery. Depending on the oversight mode you configure per mailbox, the email is either queued for approval, sent with a notification, or delivered autonomously. The Slack user who typed the command sees an immediate confirmation; the email policy is enforced regardless of how casual the command felt.

The Bolt SDK makes it straightforward to wire up slash commands and workflow steps to MultiMail's REST API. You get typed request/response shapes, webhook delivery for approval events, and an audit trail that satisfies compliance requirements — without building any of that infrastructure yourself.

Why MultiMail

Built for Slack developers

Approval queue for chat-triggered sends

Any email triggered by a slash command or workflow step enters MultiMail's pending queue when the mailbox is in `gated_send` mode. Approvers see the full message before delivery. A casual `/send-proposal` command cannot bypass review.

Per-mailbox oversight modes

Set `gated_all` on executive mailboxes, `monitored` on internal digest bots, and `autonomous` on transactional notification senders — all within the same Slack app. Oversight is a property of the mailbox, not the bot.

Webhook callbacks to Slack

MultiMail fires `message.approved`, `message.rejected`, and `message.delivered` webhooks that your Bolt app can relay back to the originating channel. The agent loop closes: Slack → MultiMail → approved → Slack notification.

Inbound email surfaced to channels

Subscribe a Slack channel to inbound webhook events on a MultiMail mailbox. Replies, tag changes, and thread updates stream to Slack in real time, making email activity visible without building a polling loop.

Identity-verified sends

MultiMail enforces that outbound email matches the authenticated mailbox identity. A Slack bot cannot spoof a From address it does not own, even if the slash command attempts to override it.

Full audit trail

Every action — send, approve, reject, tag, decide — is recorded with the originating API key, timestamp, and message ID. CAN-SPAM and GDPR audit requests are answerable without scraping Slack history.

Try it

Try it with your agent

No code, no dashboard. Paste this to your AI agent — it connects MultiMail, creates an inbox, and builds the flow for you.

1. Get MultiMail ready: read https://multimail.dev/llms.txt, connect the MultiMail MCP server to this agent, create a free inbox, and set up a verified sending domain so replies can be sent from an approved sender. 2. Wire this into Slack using real Slack mechanisms: create or update a Slack app, add a slash command for email actions, and use Slack Workflow Builder or a Slack workflow function so messages in Slack can invoke this agent’s email workflow. 3. Give the Slack agent these governed capabilities through MultiMail MCP: check the inbox, draft replies, compose new email, send email, and schedule email. Treat Slack messages as requests to prepare email actions, not as automatic permission to send. 4. Send a test email from Slack: use the slash command or workflow automation to ask the agent to draft a short test message from the verified sender to a test recipient, then have the agent prepare it through MultiMail. 5. Run MultiMail in gated_send mode for this Slack workflow. Before anything sends, show me the recipient, subject, body, and sender in Slack for review, and only send after I explicitly approve.
Getting started

Step by step

1

Create a Slack app and install Bolt

Create a new Slack app at api.slack.com/apps with `commands`, `chat:write`, and `views:open` OAuth scopes. Install the Bolt SDK.

2

Create a MultiMail mailbox and API key

Log into MultiMail and create a mailbox for your Slack agent (e.g., `agent@acme.multimail.dev`). Set oversight mode to `gated_send` so slash-command-triggered emails require approval. Generate an API key with `email:send` and `inbox:read` scopes.

3

Register MultiMail webhooks

Register your Bolt app's public endpoint to receive inbound email events and approval notifications from MultiMail.

4

Implement a slash command handler

Add a `/send-email` command in your Slack app settings pointing to your Bolt server. Implement the handler to open a modal and submit to MultiMail on confirm. See the code sample above.

5

Test the approval loop end-to-end

Use a MultiMail test API key (`mm_test_...`) to trigger the slash command without sending real email. Verify that the pending message appears in the MultiMail dashboard and that your approval webhook fires correctly.

FAQ

Common questions

Does the Slack user need a MultiMail account to send email?
No. The Bolt app holds a single MultiMail API key with permissions scoped to specific mailboxes. Slack users trigger actions through the bot — they never authenticate directly with MultiMail. Authorization is enforced at the Slack level (who can invoke the slash command) and at the MultiMail level (which mailbox the API key may access).
What happens if a slash command is invoked but the email is rejected?
When a reviewer rejects a pending message, MultiMail fires a `message.rejected` webhook to your Bolt app. Your app can relay that event back to the Slack user who initiated the command — telling them which message was rejected and by whom. The email is cancelled and never delivered.
Can I set different oversight levels for different Slack channels or commands?
Oversight mode is configured per mailbox, not per command. If you want different oversight for different workflows, create separate MultiMail mailboxes (e.g., `executive-bot@acme.multimail.dev` with `gated_all`, `notifications@acme.multimail.dev` with `autonomous`) and route each Slack command to the appropriate mailbox.
How do I prevent a Slack user from spoofing the From address?
There is no `from` field to spoof — the sender is the mailbox in the request path (`/v1/mailboxes/{mailbox_id}/send`) plus the bearer key, not a body field. The bot's API key can only send from the mailboxes it's scoped to, so a Slack user can't redirect the sender identity through the slash command. Pin the mailbox ID in your Bolt handler rather than accepting it from user input.
Is there a rate limit on slash commands triggering email sends?
MultiMail enforces rate limits per API key based on your plan tier. For burst Slack usage (e.g., a team of 50 users all hitting a command simultaneously), use a `gated_send` mailbox — queued messages are rate-limited on delivery, not on enqueueing, so users get immediate feedback while delivery is paced.
Can I use Slack Workflow Builder instead of a custom Bolt app?
Slack Workflow Builder supports custom webhook steps. You can POST to MultiMail's REST API directly from a workflow step using the webhook step type, without writing a Bolt app. However, handling approval callbacks and relaying outcomes back to Slack requires a custom listener endpoint, so a lightweight Bolt app is recommended for production use cases.
Related integrations

Explore more

Trigger.dev

workflow · typescript

View guide →

Salesforce

workflow · both

View guide →

Browser Use

tool-use · python

View guide →
Get started

The only agent email with a verifiable sender

Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.

Read the Docs →See Pricing