This is an engineering post about the foundations under SipherMail: the mail server, the protocol our apps speak, and where it all runs. We name the technology, not the machines.
Why self-host the mail server#
We run our own mail server instead of building on a hosted email API. Mail is the product, and the server decides who can deliver to you, how messages are stored, how filtering works and what is logged. Handing those decisions to a third-party service would make some of our privacy statements depend on someone else’s policies.
Self-hosting has costs. We carry the operational work: deliverability, abuse handling, upgrades, capacity and backups. We took that trade because it lets us describe, accurately, where your mail lives.
Why Stalwart#
Our mail server is Stalwart. It is a modern server written in Rust that handles SMTP, IMAP and JMAP in one program, along with calendars and contacts. The reasons we chose it:
- JMAP is built in. Not a bolt-on gateway.
- One server for the protocols we need. Fewer moving parts than combining several separate daemons.
- Hooks into delivery. Stalwart can call out to our application before accepting a message, which lets us reject abusive senders at the SMTP stage.
- A management API. We can provision accounts and app passwords programmatically.
- Mail storage is its own concern. The server stores your mail. Our application database keeps metadata and app-specific fields, such as preferences. Keeping these separate means the mail store has one owner.
None of this is a claim that Stalwart is the right choice for everyone. It fits a small team that wants to run the whole stack.
Why JMAP is the main protocol#
JMAP is a protocol for mail, contacts and calendars over HTTP and JSON. Our web and mobile apps use it as their main way to talk to the mail server.
Compared with IMAP, it fits modern apps better:
- Batching. One request can ask for a mailbox list, a page of messages and their thread information together. Fewer round trips matters on mobile networks.
- Stateless over HTTP. Requests are ordinary HTTPS calls, with no per-account session to keep open.
- Push. The server can tell an app that something changed, so the inbox updates without constant polling.
- Structured data. Messages, threads and mailboxes come back as JSON that apps can use directly.
We still use other protocols where they are the right tool.
IMAP and SMTP for your other apps#
Not everyone wants our apps, and you should not have to. Third-party mail apps connect to SipherMail over IMAP and SMTP:
| Server | Port | Security | |
|---|---|---|---|
| IMAP | mail.siphermail.com | 993 | SSL/TLS |
| SMTP | mail.siphermail.com | 587 | STARTTLS |
You sign in with an app password, which you generate in your account and can revoke at any time. It is separate from your login password. See app passwords.
SMTP is also how mail moves between servers, so it is the protocol of the whole internet’s email whichever app you use.
Where it runs#
SipherMail runs on dedicated servers in the EU, rented from Hetzner. We chose dedicated hardware over shared cloud instances because mail and storage workloads benefit from predictable performance, and because we know what else is on the machine.
The servers are split by job: one for the mail server, others for the application, the database and the AI model. Traffic between them travels over a private network, not the public internet. That keeps internal calls, such as the app asking the mail server for a mailbox, off public routes.
TLS and storage#
Connections from your device to SipherMail use TLS, and so do the IMAP and SMTP connections described above. TLS protects mail in transit between you and us.
TLS in transit is not the same as end-to-end encryption. Mail the server receives from other services, and normal messages you send, can be read by the server. Only encrypted messages are unreadable to us. We explain the difference in how end-to-end encryption works.
Stored IMAP passwords for your mailbox are encrypted at rest with AES-256-GCM.
Backups#
Backups are automated and go to a separate storage service, not just to a second disk in the same machine. Database and mail data are copied over SSH. A backup on the same server does not help if the server is lost, so keeping them elsewhere is the point.
We will not make claims here about recovery times or retention periods, because we would rather not promise numbers in a blog post. Check the status page if you want to see how the service is doing.
What this means for you#
You get fast apps on a protocol designed for them, standard IMAP and SMTP when you want another client, and a clear answer to where your mail lives: on servers we run, in the EU.
If you want to point a mail app at SipherMail, see third-party clients.