Introducing AIMX: a self-hosted, open-source email server designed for AI agents

TL;DR: I built a self-hosted open-source email server known as AIMX. It's how I imagine Postfix would look like if it is built for AI agents. Learn more at aimx.email, or view the quick 40sec-demo.

Running AI agents on their own dedicated servers has been picking up this year. A few months ago I wrote about OpenClaw, and since then Hermes Agent from Nous Research and NanoClaw have shown up. The agent-on-a-server pattern has become the talk of town. I am still not very big on these as daily drivers. I prefer my own setup around the Claude ecosystem, mostly Claude Code on servers and Claude Cowork on the desktop. But the pattern is interesting and worth taking seriously: you dedicate a whole machine to a long-lived agent, and let it do things for you while you sleep.

AIMX stands for AI Mail Exchange, named after the MX DNS records that email runs on. The thing that actually pushed me into building it started with something quite boring.

What I was actually trying to do

I spend a non-trivial amount of time on financial documents, updates and deal pitches. Statements and updates from banks, invoices from vendors, investment and startup pitches, capital calls, term sheets, distribution notices, the usual mess. Claude Code and Claude Cowork handle this kind of work remarkably well once the documents are in front of them. The bottleneck is never the analysis. The bottleneck is the part before: pulling the documents out of my inbox and getting them to the agent. I become the manual courier between the two.

Every step in that loop is me doing work that exists only because the agent and the mail are on different sides of a wall I put up myself. I was not willing to compromise on privacy the way many agentic setups do, which is to relay everything through messaging channels. Telegram is the common one. That means sensitive documents end up sitting on someone else's servers along the way, and I am not comfortable with that.

The other obvious fix is to let the agent see the mail directly, i.e. wire it up to my primary email account. Which immediately surfaces all the reasons I had not done that already.

The privacy problem comes first

I did not want an LLM rummaging through my whole Gmail. The minute you OAuth a Gmail account to an agent, you have widened the blast radius of any prompt injection to your entire correspondence history. For the bookkeeping use case specifically, the agent has no business seeing anything outside of receipts and invoices. Scoping by folder or label is not really a hard binding; it is a polite request that the model can ignore the moment something convinces it to.

The next possible step is to spin up a dedicated Gmail account for each agent. I considered it. It does not really hold up. Every account is manual signup, manual phone verification, separate credentials to store somewhere, and you are now wiring each one to some third-party Gmail MCP server because there isn't a clean first-party one. It might also potentially violate Google's ToS.

Another possibility is to use email services built specifically for AI, such as AgentMail or LobsterMail. AgentMail raised a $6M seed led by General Catalyst earlier this year and is the most prominent player. LobsterMail has a free tier and a $9/month Builder plan. Both let an agent have its own inbox and come bundled with MCP support, which is genuinely the right framing.

But the mail still lives on their server. Your agent's inbox is on their disk. Your agent's outbound goes through their relay. If the company gets acquired, pivots, raises prices, or has a breach, your agent's mail history could be part of the exposure.

All I wanted was simple: each agent gets its own dedicated mailbox, as self-sovereign as possible. It is absurd to think that the AI agent already has an entire dedicated server, and yet email still depends on a third party.

Once I started scoping it, I realized there is more to do here. If I am building an email server anyway, what does one look like when it is built for LLMs and agents from the start?

What agents actually need from a mail server

Postfix and Stalwart are what come up first when you start looking at self-hosted mail. Postfix is the battle-tested one, it has been powering Linux mail servers for decades. Stalwart is the modern Rust alternative, very capable. Both are great, but both are built for a different shape of problem than mine: hosting many users who authenticate against the server, sync mail down to their respective clients, and read it in Thunderbird or a webmail UI. That is a heavy machine. Most of what makes it heavy is wasted if your only "user" is an LLM on the same box.

A single-operator mail server built for an LLM looks quite different. Native MCP. Mail stored as Markdown so the agent can just read a file. Linux userspace for auth, so there is no separate auth layer to maintain.

So the answer to "what does an agent actually need from a mail server" turned out to be much smaller than a real mail server. Not just smaller, but designed differently and deliberately for AI agents' consumption.

The design philosophy

One operator, one domain. No multi-tenant, no virtual users. If you need that, run Postfix or Stalwart.

Markdown on disk, not .eml and not a database. Every message gets stored as a Markdown file with TOML frontmatter. Attachments are sibling files in a bundle directory. The agent reads mail by reading a file. No MIME parser, no IMAP client, no database driver. LLMs already read Markdown well. If you want to RAG or GBrain over your mail, just point your indexer at the mail directory.

Push, not poll. Inbound mail fires an on_receive hook the moment SMTP DATA completes. Outbound fires after_send when the MX attempt resolves. No cron, no heartbeat loop burning tokens checking an empty inbox. Actions trigger immediately.

Direct MTA-to-MTA, no relay. Send either delivers or fails immediately, and the agent gets to react. No retry queue, no DSNs, no bounces. It feels closer to an API call than to what is commonly associated with the email experience: best-effort store-and-forward.

Simple mailbox management for the agent. Agents should be able to spin up and manage their own mailboxes without asking a human to wire each one up. Where hard segregation between mailboxes matters, AIMX leans on Linux userspace: a user can freely create mailboxes, but only sees mail in mailboxes they own. Auth is handled by the OS, with no separate user database to maintain.

DKIM as a coarse trust gate. DKIM, defined in RFC 6376, lets a signing domain claim responsibility for a message via a public key in DNS. Every incoming message gets verified, and the result is written to the frontmatter. Hooks only fire on mail from senders you have explicitly trusted, and only after DKIM passes.

MCP over stdio. Model Context Protocol has two standard transports, stdio and Streamable HTTP. For a local mail server running on the same machine as the agent, stdio is the obvious one. The MCP spec itself notes that clients should support stdio whenever possible. The MCP server ships in the AIMX binary, with tools to list, read, send, reply, mark-read, plus mailbox CRUD. aimx agents setup wires it into Claude Code, Codex CLI, Gemini CLI, OpenCode, Goose, and the various Claw-family agents.

The shape of AIMX is also defined by what it does not have:

• No IMAP or POP3.
• No webmail.
• No SMTP AUTH.
• No retry queues. Send either delivers or fails immediately, so the agent can react in real time.
• No bounces, no DSNs.
• No indexing or search. Bring your own RAG.

Single-operator stays core to the design philosophy.

Installation and set up

AIMX is written in Rust, and installing it is drop-dead simple:

curl -fsSL https://aimx.email/install.sh | sh

That kicks off a guided setup:

1. Preflight checks on port 25 reachability
2. Set up domain and DNS
3. Set up STARTTLS certificate
4. Set up trust policy
5. Install AIMX service
6. Set up MCP for agent(s)

Quick demo

Where this goes

AIMX is open source under MIT License, on GitHub. The book goes deeper on the design and operational bits. The Discord is open if you want to talk any of it through. Please star the GitHub repository: uzyn/aimx to help on discovery if you like it.

I am running AIMX for my own agents now. The finance@ mailbox that started all this is doing exactly what I wanted it to do. Statements and invoices land, the agent reconciles them, and I am no longer the courier. A deal pitch comes in, and if I want a deeper read I forward it to analyst@ and get a thoroughly researched review five minutes later. Every morning my agent wakes me up with a summary of the day, plus the news and updates I actually care about. It has been quietly useful in a way that surprised me, because email is one of those pieces of infrastructure where boring and predictable is the whole point. And, most importantly to me, none of this sits on Telegram servers.

You can run AIMX with Claude Code, as I do, or wire it up to any AI harness that speaks MCP. Setup scripts ship for Claude Code, Codex CLI, Gemini CLI, OpenCode, Goose, and the Claw-family agents, and aimx agents setup does the wiring.

If you have an agent on a server somewhere, and the only thing standing between it and end-to-end ownership of its own correspondence is a transactional email API, this is the missing piece.

This is just the initial release. More to come. Have a look, give it a try, and let me know what you think, and what you would use it for. Comments, feedback, questions, suggestions, pull requests all welcome on GitHub or in the Discord.