Self-hosted systems

Setting up email on my own domain

Part 1. Email on my own domain, a browser inbox, and read and send access for Codex, on a server that I already had.

9 Sept 2026·5 min read
Stalwart stores messages for a custom domain while Roundcube provides the browser inbox.

I wanted to use an email address on my own domain, open the inbox in a browser, and let Codex check messages when I asked.

I already had a VPS, so I decided to host the email setup there too.

The first thing I needed to understand was which part did what. The mail server, the inbox you see in your browser, and the agent connection are separate pieces.

This is what I ended up using:

PartWhat I useWhat it does
HostingHetzner VPSRuns the services and stores mail
Mail serverStalwartSends, receives and stores messages
Browser inboxRoundcubeLets me read, write and organise email
DNS and web accessCloudflareManages DNS and protects the inbox website
Agent connectionMCPcubeGives an authorised agent access to the mailbox

Stalwart handles mail delivery through SMTP. That is the mail transfer agent, or MTA, part of the setup. It also stores the messages and lets clients connect through protocols such as IMAP.

Roundcube is the client I actually use. I open it in a browser, sign in, and get an inbox. It connects to Stalwart to read and send mail.

Both are open source.

My website can stay where it is. Email uses the same domain, but it does not need to run on the same server as the website.

Using example.com as a placeholder, the addresses look like this:

AddressPurpose
[email protected]My mailbox
mail.example.comThe mail server
inbox.example.comThe browser inbox
[email protected]An optional separate mailbox for an agent

Before setting this up on a VPS, check whether the provider allows mail hosting and outbound SMTP on port 25. You also need a stable public IP and the ability to set reverse DNS.

The server needs to be able to exchange mail with other servers.

DNS is where the domain gets connected to that server.

RecordWhat it tells other servers
AThe IP address of mail.example.com
MXWhere to deliver mail for example.com
SPFWhich servers may send for the domain
DKIMThe public key used to verify signed messages
DMARCHow to handle messages that fail its authentication checks
Reverse DNSThe hostname associated with the server’s IP

The mail hostname needs to be DNS-only in Cloudflare. Normal SMTP delivery does not go through Cloudflare’s web proxy. Reverse DNS is configured with the VPS provider.

I also needed to preserve the website during the DNS move. Before changing nameservers, the existing records had to be copied into Cloudflare. Moving email should not take the website down.

With the DNS in place, I had Codex configure the domain and mailbox in Stalwart, then connect Roundcube through encrypted IMAP and authenticated SMTP.

The server also needs the correct hostname, TLS certificates and outgoing DKIM signing. The DKIM value comes from your own installation. It is not something to copy from an example.

For the browser inbox, I wanted access restricted to me.

Roundcube listens on the server’s loopback interface. Cloudflare Tunnel connects it to inbox.example.com, and Cloudflare Access controls who can reach it.

That means I sign in twice: once to pass Cloudflare, then again to open the mailbox in Roundcube.

This protects the inbox website. Other mail servers still need to reach SMTP to deliver messages. Closing that entrance would stop incoming email.

Once the setup was running, we tested it with a real exchange. I received a message from the new mailbox in Gmail, replied, and Codex confirmed that the reply had arrived in Stalwart.

That proved sending and receiving worked. SPF, DKIM and DMARC results need their own check in the received message headers. A message arriving does not prove every authentication setting is correct.

Then I connected the agent.

MCPcube is a community Roundcube plugin that exposes mailbox operations through MCP. I started with read-only access, so Codex could list and read messages without permission to send or delete anything.

An agent can read messages through MCP, while writing and deleting remain locked

This part needed some work. We upgraded Roundcube, checked the plugin, and fixed a connection issue where it had lost the mailbox’s TLS and port settings.

Cloudflare also needed separate attention. Signing in through my browser did not automatically give Codex’s background requests access.

The connection now has two layers:

LayerWhat it allows
Cloudflare service credentialCodex can reach the protected MCP endpoint
Mailbox OAuth permissionCodex can perform the mail operations I approved

After authorising it, we tested the connection by listing the messages in my inbox. Codex could see the setup email and my reply.

I later enabled sending too. Our first test hit two compatibility bugs in the plugin. After fixing those, Codex sent an email from my mailbox to Gmail through MCP. The connection now has read and send access. Deleting mail is still disabled.

An agent does not need a separate domain for this. If I want it to have its own address, I can create a mailbox such as [email protected] and give it access to that mailbox.

It also does not start watching or replying to email just because MCP is connected. That would be another workflow to set up.

For now, I have an address on my own domain, a browser inbox, and an agent that can read and send messages when I ask.

This also gives me the building blocks for my own AgentMail-style product. The mail server handles delivery and storage, Roundcube gives me a browser inbox, and MCP gives agents access through explicit permissions.

The next part is connecting those pieces into repeatable workflows: trigger an agent when mail arrives, track delivery and failures, and retry jobs without sending duplicate replies.

Building something in this space?

I am open to talks with investors, partners and early teams.

LinkedIn