Transactional email
xpander sends sign-in codes, notifications about finished or failed runs, approval requests, and the mail an agent sends with its send-email action.
On Amazon SES, a new account is in the sandbox and delivers only to verified addresses; request production access before inviting members, and create the DKIM, MAIL FROM and DMARC records SES gives you. Without SMTP configured, the login page’s email-code flow still works: the code is generated and stored, just not sent. Print it from the cluster:
An inbox for an agent
On xpander’s cloud, the Email switch on an agent’s Channels pane gives it an address of the form<agent-name>@xpander.bot. Anything emailed or forwarded to it, messages, threads and files, becomes a run, attributed to the sender. Reply to newsletters (off by default) decides whether mailing-list mail gets an answer emailed back; the run happens either way.
On xpander’s cloud the inbound gateway is xpander’s. A self-hosted installation can run its own mailboxes: every agent gets <handle>@<your reply domain>, and the API accepts the mail at POST /v1/inbound/email?token=<INBOUND_EMAIL_TOKEN> in the Mailgun store-and-notify shape, checking the token and the Mailgun signature. Set on the chart:
aws:SourceAccount, not the legacy aws:Referer, or SES bounces the mail silently. The channel list on a self-hosted installation is on Channels.

Settings > Channels on a licensed installation: Slack, Microsoft Teams, Email and MCP as organization-wide switches. Shown with sample data.
Egress on a self-hosted install
Outbound mail goes only to the relay you configured. The hostsmailgun.net and sendgrid.com appear in the egress allowlist for xpander cloud; a self-hosted install needs neither.
