We built MailOps for our own Modoboa servers. Now it is a product

#webdev #backend #monitoring #agency

The bounce arrived on a Friday. The Modoboa message log showed rejected, the recipient's provider mentioned DMARC, and three of us were still correlating DNS records in a browser tab, Postfix logs on the server, and a domain-level SPF check that said everything looked fine.

That was not a Modoboa failure. Modoboa is a solid mail administration stack for self-hosted email. The gap was operational: host health, mailbox estate, and delivery diagnostics lived outside the admin screens we opened every day. We built Apogee MailOps for Modoboa to close that gap for our own servers first. Then we offered it as a product because the same Friday pattern kept repeating for other Modoboa operators.

Why Apogee runs self-hosted Modoboa mail

We host company mail on Modoboa because we want domains, accounts, quotas, and message history under our control without renting a mailbox product that treats deliverability as a black box. Modoboa gives us Postfix, Dovecot, Rspamd, and a web administration layer that non-mail specialists can use for everyday account work. That choice trades convenience for responsibility: when delivery fails, nobody files a ticket with a SaaS vendor. Someone on our team reads SMTP responses, checks authentication records, and decides whether the problem is DNS, reputation, mailbox state, or capacity on the host.

Self-hosted mail server management is workable when administration and operations share one environment. It is painful when every diagnostic step starts in a different tool.

Which Modoboa administration tasks still needed SSH, logs, and DNS tabs

Modoboa already covers domains and accounts, quota controls, traffic statistics, audit trails, a message log, DNS authentication checks at domain level, and IMAP migration workflows. For day-to-day mail hosting those features are enough to run a server.

What it does not consolidate is the administrator question set we repeat under pressure:

Is the host out of CPU, disk, or RAM, or is Postfix the process starving?
Which mailboxes still hold gigabytes of mail but have not been opened in months?
Does this specific failed message fail SPF, DKIM, or DMARC for the sending IP and selector that actually sent it?
Did migration finish for the accounts we thought we moved last quarter?

Vanilla Modoboa can answer pieces of those questions if you open the right module, SSH into the server, or export logs. Under incident time that becomes a scavenger hunt. SPF, DKIM, and DMARC troubleshooting for email delivery is especially brittle at domain-level checks alone: a record can look valid in DNS while the outbound path uses a different IP or a stale DKIM selector.

We were not looking for a second mail panel. We wanted operational intelligence inside the Modoboa administration environment we already trusted.

How we built the internal MailOps loop on Modoboa

The first internal version was narrow: a server health view that showed CPU, load, memory, network, and filesystem usage without opening a separate monitoring product, plus a mail-stack status strip for Postfix, Dovecot, Rspamd, Nginx, PostgreSQL, Redis, and the supporting services Modoboa depends on.

That alone saved the "is it the mail server or the host?" debate on busy afternoons. The next layer added estate visibility: domains, account counts, actual mail storage, bounce counts, and migration state in one server-level summary instead of five screens.

Mailbox operations followed naturally. Modoboa shows quota percentages against configured limits. We needed actual mailbox size and message counts in account listings, a stale-mailbox report that combined size, mail presence, and last-login date, and migration status surfaced in ordinary account views rather than only inside the migration workflow.

Delivery diagnostics were the last internal milestone. We extended the message log with route and next-hop context, then tied SPF, DKIM, and DMARC evaluation to the failed delivery attempt: sending IP, relevant DKIM record, and the SMTP failure text together. The goal was remediation guidance we could recheck after a DNS change, not another red icon with no next step.

We ran that stack on our own Modoboa servers for months before we treated it as a product. Internal tools earn trust when they survive real incidents, not demo week.

When we productised MailOps instead of folding it into Watcher

Apogee Watcher is our multi-tenant PageSpeed monitoring product. Mail server operations are adjacent to performance work for agencies, but they are not the same job. Watcher answers whether client sites meet Core Web Vitals budgets across a portfolio. MailOps answers whether our mail host is healthy, which mailboxes consume storage, and why a message bounced.

Merging those into one SKU would confuse buyers and blur the "layer, don't replace" rule we use across Apogee products. Agencies might need Watcher without self-hosted mail. Modoboa operators might need MailOps without PageSpeed monitoring. Shipping MailOps as a Modoboa extension with a permanent license and an optional complete-server deployment path keeps each product honest about what it owns.

The productisation decision was closer to operations economics than feature envy. We had already paid the maintenance cost of an internal ops layer. Licensing MailOps funds ongoing fixes inside the Modoboa ecosystem without pretending every Apogee customer runs the same stack.

Modoboa versus MailOps: what each layer owns

MailOps is designed to complement Modoboa, not replace its core administration features.

Area	Vanilla Modoboa	MailOps adds
Host and service health	No integrated CPU, RAM, load, network, disk, or mail-stack dashboard	Server Health view with operating-system and mail-service status
Mail traffic	Native statistics and graphs	Concise sent, received, and bounced activity beside estate health
Message history	Core transaction log (queue ID, status, sender, recipient)	Route and next-hop context, failure analysis, actionable diagnostics
SPF / DKIM / DMARC	Domain-level DNS authentication checks	Evaluation against the actual delivery attempt and sending path
Mailbox usage	Quota limits and percentage usage	Actual mailbox size and message counts in listings
Domain estate	Per-domain configuration	Account count and used mail storage beside each domain
Inactive mailboxes	Last-login data in separate workflows	Stale-mailbox report for accounts that still hold mail
IMAP migration	Dedicated migration workflow	Persistent migration-state visibility in normal account views

If you are evaluating Modoboa mail server administration today, treat MailOps as an operations extension for host health, mailbox estate, and bounce diagnosis. If you are evaluating PageSpeed monitoring, treat Watcher as the portfolio monitoring layer for Core Web Vitals and lab history. Different surfaces, different on-call stories, and no reason to merge them into one login.

How MailOps sits beside Apogee Watcher without duplicating monitoring

We use the same "layer, don't replace" instinct for internal tooling that we recommend for client-facing monitoring. Build or buy a focused product for the loop that repeats, then connect it to the stack you already operate instead of rip-and-replacing working tools.

For agencies scaling client coverage without hiring a monitoring specialist for every new domain, that pattern shows up clearly in Scaling Without Headcount. Automate the loops that grow with every site: scheduled tests, alerts, and client-ready reports rather than another internal dashboard maintained between billable calls.

The build-versus-buy question appears again when an internal ops tool becomes a permanent job. We wrote the agency framing for PageSpeed monitoring in Lighthouse CI versus managed monitoring: build versus buy for agencies. MailOps is our answer on the mail side: we built the Modoboa ops layer because we lived in that console daily, then productised it so the maintenance bill is explicit. Watcher is our answer on the web performance side for teams that do not want to operate a multi-tenant monitoring system themselves.

Nothing in MailOps watches LCP, INP, or CrUX field data. Nothing in Watcher diagnoses Postfix queue backlogs or DMARC alignment for a bounced invoice. Keeping that boundary clear is how we avoid a product that tries to be "everything Apogee does" in one login.

FAQ

Does MailOps replace Modoboa?

No. MailOps extends Modoboa with server observability, mailbox operations intelligence, and delivery diagnostics. Domains, accounts, quotas, and native Modoboa workflows stay in Modoboa. You still manage mail hosting in Modoboa; MailOps adds the operational views we wanted inside that same console.

Does MailOps replace Apogee Watcher or other server monitoring tools?

No. MailOps focuses on mail-server operations inside the Modoboa administration environment. Watcher focuses on PageSpeed and Core Web Vitals monitoring across client websites. You can run separate host monitoring alongside both.

How does MailOps help with SPF, DKIM, and DMARC troubleshooting?

It evaluates authentication in the context of the failed delivery: sending IP, relevant DKIM selector, SMTP response, and DNS records together, then suggests corrective actions you can verify after configuration changes. Domain-level checks alone often miss path-specific failures.

Who is MailOps for?

Modoboa administrators who self-host mail and want host health, mailbox estate visibility, and bounce diagnosis without constantly switching to SSH, spreadsheets, and external dashboards.

How is MailOps sold?

A permanent MailOps v1 license for one Modoboa server, or a complete new-server deployment that installs Modoboa and MailOps with handover. Details and pricing are on Apogee MailOps for Modoboa.

What we would ship first on a new Modoboa mail server

If we started from scratch on Modoboa today, we would still self-host mail for the control it gives us. We would also budget an ops extension early, before the third Friday bounce investigation that sends three people to three tools.

Productising internal tooling is not automatic. It made sense here because the audience already existed, the maintenance surface was real, and the boundary with Watcher was clear. If your team is building internal ops layers for stacks you operate daily, write down which incidents the tool must survive before you call it a product. That gate kept MailOps smaller and more honest than another "platform" slide.

For Modoboa operators, Apogee MailOps for Modoboa is the public home for features, licensing, and deployment options. For agency PageSpeed monitoring on the web side, start with Scaling Without Headcount or the Watcher blog index.