The problem
Like most small companies, we started with mail on a hosted platform. It worked, and for a while that was enough. But the address was on the company's own domain while the mail itself lived somewhere we did not control, subject to scanning and retention decisions we had not made and could not inspect. Every new service we added seemed to want a copy of the same data, and leaving would have meant migrating years of correspondence.
That is the ordinary shape of the problem: not a dramatic failure, just a quiet loss of control. We wanted the company's mail to be a service we ran, the way we already ran the website, with the same standard of care and the same ability to look inside.
What runs where
The domain's MX record points at mail.cmahadi.com, which is a mail server we operate. It accepts mail for the domain, stores it in mailboxes, and serves it to clients over IMAP and SMTP. Webmail is available at webmail.cmahadi.com for the times a device has no configured mail client, and the same service is reachable at mail.cmahadi.com.
The administrative interface is separate and deliberately hard to reach. It listens on the server's loopback address, not on a public port, and is opened through an SSH tunnel from a trusted machine. To an outsider it does not exist. To us it is one command away.
Making the mail trusted
A self-hosted server starts with no sending reputation, so authentication has to be complete from day one. The domain publishes an SPF record that authorises only the mail host, DKIM keys that sign outgoing messages, and a DMARC policy set to reject mail that fails those checks. Receiving providers can then tell the difference between our mail and a forgery using the domain name.
That is also a commitment: when a DNS record or a key changes, mail breaks quietly unless someone is watching. Deliverability is an ongoing operational job, not a setting that is configured once. We watch bounces and provider feedback, and we treat a blocked message as an incident rather than a user problem.
Backups and updates
Mail is the record of a company's conversations, so the backup is not optional. The server's configuration and mailbox data are backed up on a schedule, encrypted, and kept off the machine they came from. Before any update, a backup is taken and the configuration is committed to version control; if the update goes wrong, the previous state is restored rather than reconstructed.
Updates themselves are applied deliberately rather than automatically. A mail server that reboots at the wrong moment is a small outage; one that is patched into a broken state is a much larger problem.
What it costs us
This is not a zero-effort choice. Someone has to own the server, the DNS, the certificates, the backups and the reputation. It is a small amount of work most weeks and a focused amount of work when something changes. The trade is that the mail is ours: no scanning we did not agree to, no migration when a provider changes its terms, and a stack we can explain line by line.
For a company our size that is the right trade. For a larger organisation, or one with regulatory archiving requirements, a certified hosted platform may genuinely be the better answer — and we will say so.
What this means for a client
The same stack, run for your domain, is what our email hosting service is. You get the mailboxes, the webmail, the DNS authentication and the locked-down administration without having to learn the operational side. What you also get is an honest account of the limits: this suits a small or mid-sized team, and it is not a replacement for an enterprise archiving platform.