How it works
Run Your Own Email — Without Running a Mail Server
Someone you've never met types your address, writes a line, and hits send. What happens to that message in the next half-second — which machines touch it, and which of them can actually read it — is the whole story of running your own email without running a mail server. So let's follow one message, hop by hop, and ask the same question at every stop: who can read this right now?
Most explanations of self-hosted email hand you a box-and-arrow diagram and leave you to imagine the rest. This one does the opposite. We'll track a single inbound message from the instant it leaves a stranger's outbox to the instant it's sitting sealed in storage you own — then follow one reply on its way back out. No always-on machine appears anywhere in the trip, which is the point: there's nothing to keep running between messages.
The cast, in one sentence each
Four things touch your mail, and only one is a server in any sense you'd have to tend:
- Email Routing — the front door that accepts mail addressed to your domain, in place of a mailbox you'd rent.
- A Worker — a few lines of your own code that wake up only when a message arrives, do one job, and stop.
- Encrypted storage — where the sealed result rests, in your own account.
- An app on your device — the only place the key that opens your mail ever lives.
The journey in: six hops
Here is the whole inbound trip. Read the last clause of each hop as the honest part — what's readable, to whom, at that moment.
- The open internet. The sender's mail system looks up your domain and pushes the message toward it. In transit it's wrapped in the same transport encryption that carries all email between well-behaved servers — not end-to-end secrecy, just the ordinary armored truck every message rides. This hop is never yours, at any provider.
- Arrival at the front door. Your MX records point the world at Email Routing, so the message lands there instead of a rented inbox. At the instant of arrival it is plaintext — as it is on arrival at every mail system ever built, because the protocol delivers readable text. Readable, for this moment, to the receiving platform. This is the honest window, and it is identical to what happens at any big provider. The difference is what comes a breath later.
- Handoff to your code. Email Routing invokes your Worker and passes it the raw message. Now your code — not a vendor's product — holds it, in memory, plaintext, for the fraction of a second the Worker runs.
- The seal. The Worker locks the message to your public key. Think of the public key as an open padlock you've handed out: anyone can snap it shut, only the private key on your device can reopen it. The moment the padlock closes, the plaintext is gone. From here on the message is ciphertext.
- Rest. The sealed message is written to encrypted storage in your account. What sits there is scrambled bytes. The platform hosting it can't read it; neither can the people who wrote the software — there is no key on any server to compel, steal, or leak.
- You open it. You unlock the app with a passkey or Face ID. Your device, and only your device, holds the private key. It fetches the ciphertext, decrypts it locally, and shows you the message. The plaintext exists again — now only on your screen.
Lay the hops out as a table and the shape of the thing jumps out: there is exactly one moment, early and brief, when your mail is readable on infrastructure rather than on your device.
| Hop | Form of the message | Who could read it |
|---|---|---|
| Across the internet | In transit, transport-encrypted | Sending and receiving systems, as with all mail |
| Arrives at the front door | Plaintext | The receiving platform, for an instant |
| Inside your Worker | Plaintext, in memory | Your code, for a fraction of a second |
| Sealed to your key | Ciphertext | No one without your private key |
| At rest in storage | Ciphertext | No one but you |
| Open in the app | Plaintext | You, on your device |
The honest claim isn't that no machine ever sees your message. It's that the only window where it's readable off your device is the instant before the padlock closes — and from that instant until you unlock it yourself, what exists anywhere is ciphertext.
The journey back out: the reply
Answering runs the trip in reverse, with one extra dependency worth being plain about.
- You write it. The reply is composed in the app, in plaintext, on your device — the one place it's meant to be readable.
- It leaves as normal mail. The app hands the message to an email-sending provider for the last hop onto the public internet. This is the second honest caveat: getting a message delivered to the rest of the world reliably, so it lands in inboxes instead of spam, is a job for infrastructure built for it. You own the inbox and the key; the final push out rides a provider.
- It answers from the right face. A note that arrived at
billing@replies asbilling@, not from some catch-all, because the setup tracks which of your addresses the original landed on. - It crosses to the recipient like any email — transport-encrypted hop to hop, and readable by their provider on arrival. The same honest limit as hop two, now playing out on their side of the wire.
What the trip tells you
Everything people fear about self-hosting lives in the hops that aren't yours — the always-on daemon, the IP reputation, the pager. Notice that none of those appear in the journey at all. The protocol work at the front door and the final delivery hop are handled by infrastructure built to do them at scale; your part is the two moments that actually define ownership: the seal on the way in, and the key on the way out. That's the trade — hand off the drudgery, keep the padlock.
No honest version of this calls itself unhackable or perfectly private, because a message by definition travels to other people on other systems. What the journey earns you is narrower and still decisive: from the instant it's sealed to the instant you choose to read it, your mail is unreadable to everyone but you.
- Is this actually self-hosting if Cloudflare runs it?
- Yes, in the way that matters: the code is yours, it runs in your own account, and the key is yours alone. You're hosting the email on infrastructure you control rather than renting an inbox on someone else's.
- Won't my mail land in spam like other self-hosted setups?
- The common cause of that — a lone server's shaky IP reputation — doesn't apply, because sending rides on infrastructure built to deliver. Proper domain authentication records still matter and are part of the setup.
- What do I keep running day to day?
- Nothing. There's no always-on machine to patch or monitor. The receiving code runs only when a message arrives, then stops.
- Can the platform read my stored mail?
- No. Storage holds only ciphertext sealed to your key. The honest exceptions are the brief plaintext moment on arrival and the sending provider on the way out.