Yes. e2a gives an AI agent its own real, authenticated email address — on the shared agents.e2a.dev domain, or on a domain you verify yourself — that it can send from, receive to, and reply in-thread on. The inbox belongs to the agent rather than to a human whose mailbox the agent reads, so recipients can tell agent mail apart from yours and revoking the agent never touches anyone's personal mail. The agent reaches that inbox over MCP tools, a signed webhook, a WebSocket stream, REST polling, or the TypeScript and Python SDKs.

e2a evaluates SPF, every DKIM signature, and DMARC on every inbound message, then hands the agent a normalized verdict — including whether DMARC passed with alignment — as structured evidence instead of raw headers the agent has to parse and trust. That proves the message really came from the domain it claims, so mail from an agent on a verified e2a domain is distinguishable from a spoof of it. e2a treats an aligned DMARC pass as authorization to use the From domain, not as proof of a particular person or mailbox.

A transactional email API sends mail on behalf of an application; e2a gives an AI agent a two-way mailbox of its own. e2a accepts inbound mail over SMTP, verifies SPF/DKIM/DMARC, and delivers it to the agent over webhook, WebSocket, REST, or MCP, then sends the agent's replies back out in-thread through its HTTP API — with an optional approval hold and optional prompt-injection screening on the way through. The two are not mutually exclusive: e2a can use an upstream provider such as Amazon SES or Resend as the relay that carries its outbound mail to human recipients.

Yes — e2a is Apache-2.0, and the whole stack is public at github.com/tokencanopy/e2a: the Go server and SMTP relay, the TypeScript and Python SDKs, the CLI, the MCP server, and the dashboard. You can self-host it against your own Postgres and your own outbound SMTP relay, and every feature works the same way there. The hosted service at e2a.dev runs that same open-source server image, so choosing hosted is a deployment decision rather than a different product.

e2a has an opt-in human-in-the-loop approval gate you turn on per agent. With it on, an outbound send is accepted but not dispatched — the API returns 202 with status pending_review — and the message leaves only once a person approves it from the dashboard, the MCP tools, the API, or a magic link mailed to the reviewer's own inbox. A recipient allowlist can narrow the gate so only unfamiliar recipients are held, and a hold that expires without a decision can be configured to reject rather than send.

e2a can screen inbound mail before the agent ever sees it. Its opt-in content screening flags prompt-injection payloads — hidden HTML, Unicode-tag smuggling, encoded instructions — with dependency-free heuristics, and, with the optional LLM detector enabled, phishing as well; each message is then routed to allow, review, or block. Messages routed to review land in the same queue as held outbound mail, so a person decides before the agent acts on them. e2a also attaches SPF, DKIM, and DMARC results to every inbound message, so an agent can weigh how far to trust a sender instead of trusting the From header.

e2a delivers inbound mail over a WebSocket stream and plain REST polling as well as webhooks, so an agent running on a laptop, in a notebook, or behind a firewall never needs a public HTTPS endpoint. The e2a CLI's listen command bridges that stream to a local HTTP handler, and the hosted MCP server exposes the same inbox as tools for agents that run no server at all. When you do host a webhook, e2a signs every delivery with a per-webhook HMAC secret that the SDKs verify in one call.