MachineMail is an email API built for AI agents, giving each agent a real inbox it can sign up with, wait on, and reply from. The product positions itself as email for AI agents: every agent gets its own inbox for $0, mail arrives as agent-safe text with a trust level attached, and the agent reads it over MCP wherever it runs. Inboxes are not tied to a human operator — an agent can create one with a single API call, or a catch-all domain can generate addresses on demand. The site describes the product as offering email inboxes for humans and bots, with permanent addresses such as support@acme.dev sitting alongside ephemeral runner addresses that expire automatically. Everything an agent needs in order to read mail — connection, address provisioning, content sanitisation and delivery — is exposed through one Streamable HTTP MCP server or the underlying API.
Agents increasingly need to complete tasks that only email can unlock: signing up for a service, receiving a one-time code, waiting for a human reply, or accepting an invoice. Handing an agent a shared human mailbox is risky, because an inbox is an untrusted input channel — anyone can send anything, including instructions aimed at the model. MachineMail frames this as the core problem: nothing in the inbox can hijack it. Instead of passing raw MIME to an agent, the service inspects every inbound message and produces a trust report and a trust level before the agent sees any of it. The stated purpose is to make email safe for agent consumption while still giving agents a genuine, working address rather than a stub.
Connection happens from any MCP client. MachineMail runs a single Streamable HTTP server, and clients either sign in with OAuth or pass an API key, which the site notes is useful in CI. The documented command is `claude mcp add --transport http machinemail https://mcp.machinemail.dev/mcp`. The site lists Claude Code, Codex, OpenCode and Copilot as supported clients, and the signup page says the product works with Cursor, Codex, Claude Code and OpenCode, offering a copyable agent prompt. Because the interface is a standard MCP endpoint over HTTP rather than a bespoke SDK, an agent running in a local editor, a hosted environment or a CI pipeline can attach to the same server. Connecting is step one of the documented flow, followed by addresses, trust and delivery.
Each agent gets its own inbox. Addresses can be created explicitly with one API call, or implicitly through catch-all domains: point a domain at MachineMail and any address on it works, with the inbox appearing on first delivery. The site's example domain, acme.dev, shows a mix of addresses — signup-7f3k@acme.dev expiring in 24 hours, otp-runner@acme.dev expiring in 23 hours, invoice-intake@acme.dev expiring in 6 days, and permanent addresses like qa-bot-12@acme.dev and support@acme.dev. That mix illustrates the intended pattern: short-lived addresses for one-off tasks and durable ones for standing roles. The site states there are no inbox fees — $0 per inbox and trust report on every plan — with the Free plan covering 3,000 messages a month and paid plans starting at $9.
The trust layer is the product's central differentiator. Every inbound message gets a trust report and a trust level before an agent is allowed to see it. Content is converted into agent-safe text, and hidden instructions are removed before the agent reads a word. The site illustrates this with a message from paypa1-payouts.ru that fails DMARC authentication, has a link with a display mismatch, and carries the hidden text "ignore previous instructions" — the hidden portion is stripped and the message is assigned the level quarantined. The trust report lists every reason it used, and the underpinning checks combine SPF, DKIM and DMARC alignment, your allow and block lists, prior correspondence, link and attachment checks, and a classifier. Rather than asking an agent to judge a sender's claims, MachineMail gives it a pre-computed verdict and the evidence behind it.
Trust resolves to five levels, and the documented guidance is that your agent acts on the level, never on what the sender says. A verified message is one the agent can act on; a known message is one it summarises; an unknown message it reads only; a suspicious message it uses for reasons only; and a quarantined message is withheld entirely. That ladder lets developers encode a policy once — for example, allow automatic action only on verified mail, summarise known senders, and escalate the rest to a human or a log — instead of writing per-sender heuristics. Because the level is attached to the message rather than inferred by the model at read time, the decision is consistent across agents and can be inspected after the fact in the trust report.
Delivery is exposed two ways: webhooks and MCP. Webhooks are signed, retried for five days, and replayable from the dashboard, with events such as inbox.created, message.received, message.received.quarantined and message.bounced. Bounces are reported with retry behaviour visible in the event stream — the site's example shows a 503 that retries and then succeeds. On the MCP side, wait_for_message holds the call open until mail lands, for up to a minute, which removes polling loops from agent code. The site's example shows a wait returning the sender no-reply@acme.dev, a verified trust level, and the body "Your code is 482 913". In practice webhooks suit applications that own their own queue and processing, while wait_for_message suits an agent that needs to pause mid-task and resume the moment a message arrives.
The Free plan costs $0 and covers 3,000 messages a month; paid plans start at $9 a month, and the Product Hunt launch offers 50% off any plan for three months. Message counting is defined precisely: each inbound delivery and each outbound send counts as a message, while spam, quarantined and rejected mail do not count, and neither do drafts until they are sent. That definition matters for agents working with untrusted inboxes, because the messages most likely to arrive in bulk — spam and quarantined content — are the ones excluded from the quota. API keys are self-serve: create a free account and make keys in the dashboard under API keys, with no sales call required.
Agents can provision themselves. The documented flow: paste the agent prompt into Claude Code, Cursor or any MCP client; the agent registers itself through auth.md, receives a sandbox key and one ephemeral inbox, and displays a six-digit code; you enter that code at /claim to bind the agent to your organization. Ephemeral inboxes are cleaned up by a reaper that deletes the inbox along with its messages, raw MIME and attachments, then emits an inbox.expired event. Receiving new mail before expiry pushes the deadline out, so an address that is still in active use does not disappear mid-conversation. Together, self-registration and automatic expiry let a developer spin up agents without manual mailbox administration, while keeping a human approval step — the six-digit claim code — between a new agent and an organizational account.
The site's own examples sketch the use cases: signup and OTP addresses such as signup-7f3k@acme.dev and otp-runner@acme.dev for services that verify by email; an invoice-intake address that lives for days rather than minutes; and standing addresses like qa-bot-12@acme.dev and support@acme.dev for testing and support workflows that involve both humans and bots. The wait_for_message tool points at flows where an agent must pause for an inbound code or reply, such as a verification step in the middle of a longer task. Webhook events with replay suit teams that want to process mail in their own stack and re-run failed deliveries from the dashboard.
MachineMail is aimed at developers building agent workflows — teams using MCP clients like Claude Code, Cursor, Codex, OpenCode or Copilot, and engineers wiring agents into CI with an API key. It fits wherever an agent needs a genuine address but the operator does not want an untrusted inbox flowing straight into a model. The proposition is narrow and concrete: real inboxes for agents, free at $0 with 3,000 messages a month, a trust report on every message, and an API described as AgentMail-compatible. The value is that email becomes a usable tool for agents without becoming a new attack surface.