Security
What protects your mail, and what does not yet.
The posture as it actually stands. Every claim here is something running in production today, and the second half of the page is the list of things that are not.
Mail in transit
Client connections are TLS only
Connections from mail clients are encrypted: IMAP over TLS on 993, and submission over an authenticated, encrypted channel. There is no unencrypted path to a mailbox.
Server to server, TLS where the other side offers it
Mail between servers uses opportunistic TLS, which is what SMTP supports. That protects the hop when the other side offers it, and every sending provider of any size does. It cannot protect a hop that happened before the message reached us.
Mail at rest
Stored unencrypted, protected by access control
Mail in a Smart mailbox is stored unencrypted. What protects it is access control rather than cryptography: the store is reachable only from the mail host, the control plane is under row-level security, and the data stays in the EU. We are technically capable of reading message contents — that is what makes server-side search, filtering and integrations work — and no key-custody arrangement softens that.
Zero-access storage is not shipped
Private mailboxes are designed so that protected contents are encrypted for the account holder rather than readable by our servers. That work is not finished and nothing on this page describes it as available.
Authenticating your domain
Records written and verified for you
MX, SPF, DKIM and DMARC are written and then checked until they resolve, per domain rather than once per account. Getting these wrong is the most common reason mail from a new domain lands in spam, and it is the part we do not leave to a documentation page.
Inbound scored, outbound checked
Every inbound message is scored by Rspamd before delivery, with SPF, DKIM, DMARC, sender reputation and phishing heuristics feeding the score. Outbound is checked as well, which is less common and is what stops one bad account degrading delivery for everyone else.
The control plane
Row-level security, counted
Account, domain and mailbox records live in Postgres with row-level security enabled on 23 tables under 34 policies. Access is scoped by the database rather than by application code remembering to filter, which is the difference between a bug being a bug and a bug being a data leak.
Bot protection and key handling
Sign-up is protected by Cloudflare Turnstile, verified by the auth service rather than by the app. The service-role key that bypasses row-level security is server-side only and never reaches a browser.
Where it lives
Mail data stays in the EU
Mailbox contents are stored on servers in Finland, inside the European Union. The control plane runs in an EU region. The full processor list, with what each one does, is published rather than available on request.
Mature components, not in-house rewrites
Postfix, Dovecot and Rspamd — the same components most mail providers run. We did not write our own IMAP server, because a fresh implementation of a thirty-year-old adversarial protocol would be less secure than the one everyone has been attacking for decades.
What we do not have
Four real absences, at the same size as everything above them. If any of these is a blocker for you, it is better that you know now.
No encryption at rest
Mail is written to an ordinary filesystem on the mail host, and that volume is not an encrypted one either. At-rest encryption is planned and is not in place, so a disk that left the building would carry readable mail. Transport is still encrypted, and so is everything in the control plane's own storage — this is about the message store specifically.
No two-factor authentication yet
Accounts are protected by a password and nothing else. Multi-factor authentication is not enabled, and until it is, an account is exactly as strong as the password on it. This is the gap on this page we would close first.
No external audit or certification
No SOC 2, no ISO 27001, and no third-party penetration test. Those cost real money and take real time, and we would rather tell you they are absent than imply a programme that has not started.
MTA-STS is written but not live
MTA-STS tells other providers to refuse to deliver to us over an unencrypted connection. The policy file exists; the DNS records that make it take effect are not published yet, so it currently protects nothing.
No published backup policy
There is no published backup and restore policy, because there is not yet a documented one to publish. Keep your own copy of anything you cannot lose — which is good advice about any mail provider, including the large ones.
Found something?
Write to security@ruber.me. We will not pursue anyone acting in good faith, we will credit you if you want crediting, and there is no paid bounty — saying so is more useful than leaving you to guess.