Your agent shouldn't need a SendGrid account, a verified domain, and a webhook server just to answer an email. On a2a cloud, resources.mailbox: true gives a Pro-plan agent its own address at agents.a2acloud.io — IMAP and SMTP creds injected as environment variables, ctx.mail in the SDK, and a structured handler for inbound mail. Provisioned in seconds, round-tripping in seconds.
A2A_MAIL_* injected · ctx.mail · on_email handler · no provider wiring
Every serious agent eventually needs to receive and send email — status requests, approvals, customer threads. The conventional path is a transactional-mail provider for outbound, an inbound-parse webhook for incoming, DNS records to verify, MIME parsing to write, threading headers to hand-roll, and an API key with account-wide send rights sitting in an env var. That's days of integration work for a capability the agent should simply have — and the failure modes (loops, spoofed From headers, burned domain reputation) all land on you.
a2a cloud treats email like Postgres or the API: a resource the runtime provisions and injects. The agent gets its own address on a dedicated, fully authenticated subdomain; your code gets ctx.mail and a typed inbound payload. Governed agent execution, now with an inbox.
Set resources.mailbox: true in a2a.yaml and the runtime injects A2A_MAIL_ADDRESS, A2A_MAIL_PASSWORD, and A2A_MAIL_HOSTS into the agent's environment. IMAP on 993, SMTP on 587 — standard protocols, provisioned in seconds, zero provider signup.
The SDK wraps the injected creds in ctx.mail: list_messages, read, send, and reply. Your agent code never touches raw IMAP folders or SMTP envelopes — and never sees a SendGrid or SES API key, because there isn't one.
Decorate a function with @a2a.tool(on_email=True) and it receives (ctx, email: InboundEmailPayload) — sender, subject, body, message_id, date, references, attachments. Return a str or {body, subject} and the runtime sends the reply. This handler contract ships in the next a2a-pack release; the inbox itself is live today.
Replies go out from the agent's own address with In-Reply-To and References set, so conversations thread correctly in every mail client. Outbound mail carries the Auto-Submitted header, which keeps remote autoresponders from bouncing your agent into a loop.
Every Pro-plan agent gets <agent-name>@agents.a2acloud.io on a dedicated mail subdomain with SPF, DKIM, and DMARC already configured. You never touch DNS, and agent mail can't damage your primary domain's reputation.
The injected SMTP credentials can only send as the agent's own address — From is locked at the transport layer. A prompt-injected agent cannot spoof you, your CEO, or another agent, no matter what the model generates.
Sign up for SendGrid or SES, verify a domain, wire DNS records, mint an API key, store it, write webhook endpoints for inbound.
One line — resources.mailbox: true — or one dashboard click. Address, DNS, and creds provisioned in seconds.
Parse raw MIME from a webhook POST, or poll a shared inbox and pray your parsing code keeps up with encodings.
A typed InboundEmailPayload handed to your @a2a.tool(on_email=True) handler, or ctx.mail.list_messages when you want to pull.
A provider API key with account-wide send rights, living in an env var you manage and rotate.
Per-agent IMAP/SMTP creds injected by the runtime, From locked to the agent's own address.
Hand-roll In-Reply-To headers; discover autoresponder loops in production when two bots email each other forever.
References threading and the Auto-Submitted header set by the runtime; auto-submitted inbound is filtered before it reaches your handler.
Agent mail sends from your domain — one bad batch and your company's deliverability takes the hit.
A dedicated agents.a2acloud.io subdomain isolates reputation, with a 50 outbound/day cap per agent.
Every Pro-plan agent can have its own mailbox at <agent-name>@agents.a2acloud.io, enabled with resources.mailbox: true in a2a.yaml or one dashboard click. The runtime injects IMAP (993) and SMTP (587) credentials as A2A_MAIL_* environment variables, and the SDK exposes them as ctx.mail with list_messages, read, send, and reply. Email becomes a capability the agent has, not an integration you build.
No. The mailbox is part of the a2a cloud runtime — no third-party provider account, no API key, no webhook endpoints. SPF, DKIM, and DMARC are already configured on the dedicated agents.a2acloud.io subdomain, so a verified reply round-trips in seconds without any DNS work on your side.
Two ways. Pull: call ctx.mail.list_messages and read over the injected IMAP creds. Push: decorate a function with @a2a.tool(on_email=True) and the runtime invokes it with a structured InboundEmailPayload — sender, subject, body, message_id, date, references, and attachments up to 1 MiB each (metadata-only above that). The on_email contract ships in the next a2a-pack release; inbox, threads, and replies are live today.
No — and that's deliberate. The injected SMTP credentials lock From to the agent's own address, so even a fully compromised prompt can't impersonate a human or another agent. Combined with the 50 outbound/day cap and an audit event for every sent mail, the send path stays bounded and provable.
50 outbound emails per day per agent, a 100 MiB mailbox quota, and attachments delivered as base64 up to 1 MiB each. Over-cap replies stay in the dashboard thread and are audited rather than silently dropped. If your plan lapses, mail is retained for 30 days; the mailbox is removed when the agent is.
All guides live in the guides index.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — with managed Postgres, an MCP server, an API, and now a mailbox on a dedicated authenticated subdomain. Injected IMAP/SMTP creds, ctx.mail in the SDK, From locked to the agent's own address, and an audit event for every message in or out. Email as a capability, not an integration.
