Jelia.nyc

Jelia.nyc / Proof / Mailboxes, self-hosted

PROOF · MAILBOXES

Running your own mail, properly

There are 244 mailboxes across 39 domains on this estate, on a mail server I run myself. Self-hosted mail is entirely doable; it is just less forgiving than most things, and it is worth knowing what it asks of you.

What the number means

Two hundred and forty-four mailboxes, spread across the 39 domains on this estate, all delivered to and sent from a mail server I run. No hosted mail provider sits in the middle. Messages are received, filtered, stored and served from infrastructure I own, and people read them in Roundcube webmail or any ordinary mail client.

The same server carries the mailing lists, through Mailman 3. Lists are where self-hosted mail gets tested hardest, because one message turns into many, and every copy has to arrive looking legitimate.

What sits behind it

244mailboxes across 39 domains
Postfix + Dovecotsending, receiving and storage, run as docker-mailserver
SPF, DKIM, DMARCon every sending domain, verified passing at Gmail
One loginwebmail and lists sit behind the estate's single sign-on

Postfix moves the mail; Dovecot stores it and serves it to clients. Both run in a container from the docker-mailserver project, which bundles them with sensible defaults for spam filtering and the rest. Roundcube is the webmail. Mailman 3 runs the lists.

Whether mail is accepted at the other end depends on three DNS records per domain. SPF lists the servers allowed to send for the domain. DKIM signs every outgoing message so the receiver can tell it was not altered. DMARC tells receivers what to do when those checks fail, and sends reports back. All three are in place for every sending domain here, and they are checked by sending real mail and reading the verdict — not by assuming that because the records exist, they work.

What self-hosting really takes

  1. Authentication that passes. SPF, DKIM and DMARC have to be correct for every domain, and kept correct when anything changes. One wrong record and a whole domain's mail goes to spam without anyone being told.
  2. Reputation. Large mail providers judge a server by its history. That means a clean sending address, correct reverse DNS, no open relay, and not letting a compromised account send spam for an afternoon.
  3. Spam filtering inbound. Most mail arriving at any server is junk. Filtering has to catch it without swallowing the invoice that happens to look odd.
  4. Backups. Nightly database dumps are pulled off the server to separate storage, and the whole machine gets a weekly full-disk snapshot. Mail that exists in one place only is a liability.
  5. Monitoring. The mail front ends are probed every five minutes alongside everything else, certificates are swept daily, and alerts go to a person.

When hosted mail is the better answer

I will say this plainly, because it is the honest answer for a lot of organisations: if nobody on your side can own a mail server, pay someone to host your mail. Microsoft 365 and Google Workspace are good at it, and their scale gives them reputation you cannot buy.

Self-hosting makes sense when you want control over where the data lives, when you have many small domains whose per-seat costs add up, or when the mail is tied closely to other systems you already run. Either way, the authentication records are your job. A hosted provider will not fix your DMARC for you.

Questions people ask

Will our mail end up in spam if we self-host?

Not if authentication passes and the server's reputation is kept clean. Most deliverability problems I see on hosted platforms are DNS mistakes, not the platform.

Can people keep using Outlook or their phone's mail app?

Yes. Standard mail clients connect normally. Webmail is there for when they are away from their own device.

Can you just fix our SPF, DKIM and DMARC without moving anything?

Yes. That is often the most valuable small piece of work in an audit, whatever platform the mail sits on.