Email hosting for developers: mailboxes you control, not an email API

Two different products answer to “email for developers”. One sends mail from your application — SES, Postmark, Resend, a hundred others — and does not want to keep it. This article is about the other kind: the mailbox a human reads, on a domain you own, with the archive sitting in storage you already pay for.

Do you want email hosting or an email API?

If code sends the message, you want an API. If a person reads the message, you want hosting. They are not substitutes and they are not competitors: transactional providers exist to hand mail off and report on it, mailbox hosts exist to receive mail, keep it and let you search it. Most of us need both, on different addresses of the same domain.

Everything below is the second kind. Nisdos Mail runs MX for your domain, authenticates and filters inbound mail, encrypts each message with a per-mailbox key and writes it into your own S3 bucket, R2 bucket, WebDAV server or Git repository.

What do developers want that a per-seat suite doesn’t give them?

Three things, and more storage is not one of them.

An address per thing, not per person. A suite priced per user pushes you toward one identity and a folder tree. Unlimited addresses on your own domain let routing do the work instead: stripe@, alerts-staging@, receipts@, one address per vendor account, one per project. When a service leaks its list, the spam arrives at the address you gave that service and names the source in its own To: header. When a project ends, you delete a channel rather than untangling filters.

Storage in the account they already reconcile. If your infrastructure is in one cloud account with one bill, one IAM story and one backup policy, mail is the odd exception — a vendor’s opaque quota with an export button. Pointing mailboxes at a bucket in that same account makes mail obey the rules you already wrote: versioning, lifecycle, replication, access logs.

A bill that scales with data, not headcount. Per-seat plans make sense for a company of employees and no sense for one developer with four projects, eight role addresses and a build robot. Nisdos Mail’s users, aliases and domains are unlimited under fair-use terms; the meter is storage, at $2 per 25 GB per month if we host it, or your provider’s rate if you bring your own bucket. EU-resident hosted storage adds $1 per 25 GB.

Why is an address per project better than a filter?

Because an address is a fact about the sender, while a filter is a guess about the mail. Filters break when a vendor changes its sending domain. An address you invented for exactly one purpose keeps its meaning for as long as the purpose exists, and it fails loudly rather than silently: mail to alerts-staging@ cannot end up in the wrong place because someone edited a rule.

It also gives you an isolation boundary you can revoke. One address per vendor account means a compromised vendor account is traceable to one address and killable by deleting it, without touching the login for anything else. This is the same instinct as a separate API key per service, applied to the identity you sign up with.

Can you grep your mail archive?

On terms you choose, because encryption is a per-mailbox setting rather than a product-wide one. Point a mailbox at a Git repository and the archive arrives as files under version control, with the history that implies — an alerts or receipts mailbox becomes a directory you can search with the tools you already use on logs. A mailbox on the encrypted tier is opaque to grep by design, which is exactly what you want for personal mail. The point is that the two mailboxes do not have to make the same choice.

Inside webmail, search takes the operators you already type: from:, has:attachment, newer:7d, in:anywhere, with keyboard navigation and labels that behave like folders.

Should you just run Postfix and Dovecot instead?

Sometimes yes — if you already operate mail for other people and the muscle exists, self-hosting gives you everything with no vendor in the path.

For everyone else the estimate is wrong in a specific way. Standing up Postfix, Dovecot, Rspamd and a certificate renewal is a weekend, and it is not the work. The work is the decade after: blocklist monitoring, reverse DNS, IP warm-up, TLS renewals that fail on a holiday, spam rules that decay, and the afternoon a large receiver quietly starts filing your domain in spam with nothing in your logs to say why. Outbound deliverability is decided by other people’s reputation systems, and a fresh IP on a small block does not get a fair hearing no matter how correct your configuration is.

Bring-your-own-storage hosting splits the stack the other way: someone else owns the reputation problem, you own the bytes. If what you actually wanted from self-hosting was custody rather than the daemon, that is the trade on offer.

What is missing, honestly?

Worth knowing before you move a domain.

Clients: webmail today, with an IMAP bridge still on the way — a terminal mail workflow is not there yet. Scope: mail only, so no calendar, no drive, no shared directory, and a team leaving Workspace keeps paying Workspace for the rest. Sending: rate-limited to keep the platform off blocklists, starting at 10 messages an hour on a free account and ramping to 50 over the first 30 days, with every 25 GB of paid storage adding another 50 an hour. Keys: on the default tier we hold the per-mailbox keys so the mailbox can render in a browser; the tier where we cannot read your mail at all is in beta. Status: early access, which is a real answer to “should this hold my company’s mail next quarter” and the answer is “bring a side project first”.

Developer email hosting is a small category mostly because most developers gave up and pointed a custom domain at Gmail. That works fine. It just means the archive belongs to Google, the address count is a plan limit, and the bill grows with your team instead of your data.