Self-hosted mail infrastructure
Production transactional-mail infrastructure, self-hosted and operated end to end — from MTA daemons and DNS auth records to deliverability monitoring.
Email is the layer of the stack most developers rent, because running it yourself means volunteering for DNS records, IP reputation, TLS on port 587, and debugging why one receiving host greylists you at 3am. I run it anyway — a production mail platform for transactional sending, plus the self-hosted MTA that carries my own applications’ mail.
What “running mail” actually means
- The MTA stack itself — Postfix and ZoneMTA deployed in containers, with the chroot quirks, alias databases, and daemon supervision that entails. Nine daemons have to agree with each other before a single message moves.
- Authentication as code — SPF, DKIM signing with per-domain keys, DMARC policy. A message that fails alignment is a message that lands in spam, so the records and the signer are treated as one system, not two chores.
- Deliverability as an operational discipline — external round-trip checks that score SPF/DKIM from a receiver’s perspective, port-25 reachability verified from multiple external vantage points (a lesson learned the hard way: your own network lies to you about port 25), and queue monitoring so a stuck message is a page, not a surprise.
- Upgrades without downtime — engine updates that preserve DKIM keys and certificates across container replacement, with config snapshots taken before every change and a verified end-to-end send after.
Why it’s worth it
Because owning the failure modes changes how you build on top — including the Mailniaga Gateway console, where relay management and delivery analytics (on ClickHouse) sit on top of this same infrastructure. Application code that sends mail through infrastructure you operate is written more carefully: idempotent sends, meaningful bounce handling, one shared transactional sender instead of a mailbox per app. And when something breaks, the debugging surface is yours all the way down.