Route deployment notices, incident alerts, and release summaries through MultiMail's approval and identity layer — so automated CI events don't flood inboxes unchecked.
GitHub Actions workflows trigger on push, pull request, release, schedule, and dozens of other repository events. When those workflows need to send email — deployment notices, failure alerts, security scan results, release announcements — they typically use raw SMTP or a transactional service with no controls on who can send what to whom.
MultiMail gives GitHub Actions a managed email surface with oversight modes, identity verification, and per-workflow policy enforcement. A workflow step calls the MultiMail REST API directly using a stored secret. The API handles delivery, logging, and — if configured — human approval before any message leaves your domain.
CI pipelines can generate email volume fast. A failed deployment that retries five times produces five alert emails. MultiMail's `gated_send` mode lets you require a human to approve before batches of automated messages go out, while `monitored` mode delivers immediately but logs every send for audit. You pick the tradeoff per workflow, not globally.
Set a workflow's mailbox to `gated_send` or `gated_all` and no message leaves until a human approves it via the MultiMail dashboard or API. Stops alert storms and accidental mass-sends before they reach recipients.
Every email sent through MultiMail is recorded with the sending identity, timestamp, recipient, and approval status. You can correlate email sends back to specific workflow runs using custom headers or subject prefixes.
Each workflow can send from a dedicated mailbox — `[email protected]` or your own domain — so recipients can distinguish deployment notices from incident alerts from release announcements by sender alone.
MultiMail uses Bearer token auth (`MM_API_KEY` stored as a GitHub Actions secret). No SMTP host, port, username, or password to rotate. Tokens can be scoped per mailbox and revoked without touching workflow YAML.
Workflows that loop or retry can easily send duplicate alerts. MultiMail enforces per-mailbox send limits and supports idempotency keys so retried workflow steps don't produce duplicate emails.
MultiMail's oversight, identity, and authorization models are proven correct in Lean 4. When your CI pipeline sends an email, the policy enforcement isn't best-effort — it's mathematically verified.
No code, no dashboard. Paste this to your AI agent — it connects MultiMail, creates an inbox, and builds the flow for you.
Sign up at multimail.dev and create a dedicated mailbox for CI notifications. Use a `@multimail.dev` address like `deploys` or a local address on your own verified domain. Set the oversight mode to `gated_send` for a safe starting point. Creating a mailbox requires an admin-scope key.
In your GitHub repository, go to Settings → Secrets and variables → Actions → New repository secret. Name it `MM_API_KEY` and paste your `mm_live_...` token. For organizations, store it as an organization secret to share across multiple repositories.
Insert a send step after the job step you want to report on. Use `if: success()` or `if: failure()` to control when the notification fires. Include `github.sha`, `github.actor`, and `github.run_id` in the message body for traceability.
If using `gated_send`, log into the MultiMail dashboard to approve the first test sends and confirm the message content looks correct. Once satisfied with the format, switch the mailbox to `monitored` or `autonomous` if human approval per-send is not required for this workflow.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.