Give your AI agents a real, authenticated email address — with SPF/DKIM-verified inbound, HMAC-signed delivery, WebSocket fan-out, and human-in-the-loop approval built in.
e2a is an open-source email gateway purpose-built for AI agents. Unlike generic SMTP libraries or webhook-forwarding hacks, e2a treats agents as first-class email citizens: each agent gets its own address, and every email it receives is cryptographically verified before delivery. SPF/DKIM checks run on inbound messages, and a set of HMAC-signed X-E2A-Auth-* headers are appended so receiving agents can confirm the sender identity without trusting raw SMTP metadata.
Delivery adapts to how the agent runs. Cloud-hosted agents get emails pushed as HTTP webhook POSTs the moment they arrive. Local agents — running on a developer laptop without a public URL — connect over WebSocket and receive the same real-time notifications, with messages queued while offline and drained on reconnect. Both paths share the same REST API, so switching modes is a single attribute change on the agent record.
For agentic workflows that involve humans, e2a includes an optional human-in-the-loop gate. When enabled, outbound messages from an agent pause in a pending_approval state; a reviewer can approve or reject via the dashboard, a one-click magic-link email, or the CLI. Configurable TTLs and expiration actions (auto-send or discard) keep flows moving even without a reviewer online.
The project ships TypeScript and Python SDKs, a e2a CLI, an MCP server for Claude Code integration, and an OpenAPI spec with a generated dashboard. It is licensed under Apache 2.0 and designed to run on any Docker host, with PostgreSQL as the only stateful dependency.
X-E2A-Auth-* headers on every delivered message binding the signature to both the message ID and a SHA-256 body hash — replay attacks and body substitution are cryptographically preventedpending_approval state, releasable via dashboard, magic-link email, or CLI, with configurable TTL and expiration actionemail.sender on an unverified payload raises UnverifiedEmailError so accidental trust is prevented at the API levelArchitecture e2a follows a layered, modular architecture organized around a small set of well-defined internal packages — relay, httpapi, delivery, identity, ws, webhookpub, hitlworker — each with a single responsibility and injected collaborators rather than hard-wired dependencies. The inbound path flows from an SMTP listener through SPF/DKIM checking, agent lookup, HMAC signing, and fan-out to either a transactional outbox (for webhook subscribers) or a WebSocket hub (for local agents), with both paths able to coexist and the outbox gated behind a feature flag for incremental rollout. The HTTP API layer uses narrow function-type injection instead of broad interface embedding, which keeps individual handlers testable in isolation without a full server context. The HITL subsystem runs as an independent background worker with its own state machine over message status columns, decoupled from both the relay and the API by the same injected-collaborator pattern. The design is explicitly slice-oriented — internal comments reference design paragraph numbers and slice identifiers — indicating a planned, incremental delivery model where features ship behind feature flags and the default behavior degrades gracefully when optional components are absent.
Tech Stack The backend is written in Go 1.25 using go-smtp for the SMTP server, go-chi and the Huma v2 framework for the HTTP API (which generates an OpenAPI spec from handler annotations), pgx/v5 for PostgreSQL access, River for background job processing, nhooyr.io/websocket for WebSocket connections, and the AWS SDK v2 SES integration for outbound delivery to humans. SPF verification uses blitiri.com.ar/go/spf and DKIM signing uses go-msgauth. The dashboard is a Next.js application served behind Caddy, which also handles TLS termination. Client SDKs are shipped as a TypeScript npm package and a Python PyPI package, each with their own test suites. The CLI is distributed as an npm package. An MCP server is included for Model Context Protocol integration. PostgreSQL is the sole stateful dependency, accessed via a pgxpool connection pool, with SQL migrations managed as plain idempotent SQL files.
Code Quality e2a has extensive test coverage — over 130 Go test files across the internal packages — exercising individual handlers, the SMTP relay flow, outbound idempotency, rate limiting, domain conflict detection, conversation threading, and the WebSocket hub. The testing approach is unit-first with injected fakes rather than integration test mocks, keeping individual tests fast. Error handling is explicit throughout: the HTTP API uses typed error structs that map to specific HTTP status codes, and the relay discards or bounces messages via explicit policy decisions rather than swallowing errors silently. The codebase runs Go’s standard linting toolchain with CI enforcing test passage on every PR. TypeScript and Python SDKs have their own test suites using Vitest and pytest respectively. Comments are thorough and frequently reference the design document by section number, making the intent behind non-obvious implementation decisions traceable.
What Makes It Unique
e2a occupies a gap that existing tools leave open: SMTP was not designed for machine-to-machine trust, and bolting webhook delivery onto a generic mail server means either trusting SMTP envelope headers (forgeable) or building custom auth on top. e2a closes this by making cryptographic identity a first-class delivery primitive rather than an afterthought — the HMAC signature binds to a body hash and a message ID simultaneously, so neither header replay nor body substitution can produce a valid signature. The dual delivery mode design (webhook for cloud, WebSocket for local) is specifically engineered for the local-agent use case where developers cannot expose a public URL, which general-purpose webhook infrastructure does not address. The HITL gate is integrated at the protocol level rather than as an application-layer wrapper, meaning any agent can opt into approval flows without modifying its send logic. The SDK-level UnverifiedEmailError guard makes it structurally difficult to accidentally trust attacker-controlled fields, a security property that few webhook delivery systems enforce at the client library layer.
e2a is released under the Apache License 2.0, a permissive open-source license that allows commercial use, modification, and redistribution without copyleft obligations. You can run e2a inside a private deployment, embed it in a commercial product, or build paid services on top of it — with no requirement to open-source your own code. The only obligations are preserving copyright notices and the NOTICE file.
Running e2a yourself requires Docker (the only hard prerequisite), PostgreSQL for message storage and agent records, and an SMTP-capable relay for outbound mail to humans (e.g. Amazon SES, Resend, or Postfix). A DNS MX record pointing to your server is needed for real inbound email; without it the REST API and WebSocket paths still work for testing. The compose file handles migrations automatically on first start but subsequent schema migrations must be applied manually — the migration files are idempotent so re-running them is safe. You are responsible for PostgreSQL backups, TLS termination (Caddy is included and handles it), SMTP deliverability configuration, and rolling your own updates when new releases ship.
The hosted instance at e2a.dev adds a shared agents.e2a.dev domain for instant slug-based onboarding without DNS setup, managed deliverability, a hosted dashboard, and presumably SLA-backed uptime. Self-hosting gives you full control over data residency and the ability to customize the relay behavior, but you trade the operational simplicity of a managed service for the burden of keeping PostgreSQL healthy, configuring DKIM signing on your own mail domain, and monitoring the relay process. There is no enterprise licensing tier or feature-gated commercial add-on documented in the repository — all features are available in the open-source build.
Automation · Productivity · AI Assistants
Build, deploy, and run autonomous AI agents that automate complex multi-step workflows using a visual block-based graph editor.
Devops · Automation · Security
A cloud-native reverse proxy and load balancer that auto-configures itself from Docker, Kubernetes, and other orchestrators — zero manual routing required.
Developer Tools · Automation · AI Assistants
The all-in-one AI platform for private document chat, no-code agents, and local LLMs with zero setup friction.