Self-hosted mail vs Google Workspace vs Microsoft 365: when self-hosting is worth it

01The three cases where self-hosting wins

Licensing economics at headcount. Per-seat pricing is excellent value at twenty users and a substantial annual line at four hundred. Somewhere in between, the infrastructure and operational cost of self-hosting becomes lower than the licence bill - and that crossover moves depending on how much of the suite you actually use.

Data residency or sovereignty a hosted suite cannot satisfy. And programmatic control - if your product needs mailboxes as a feature rather than mail as a tool, self-hosting gives you interfaces a suite will not expose.

• Licensing cost has become material at your headcount.
• Residency or sovereignty rules the suites cannot meet.
• Your product needs mailboxes as a feature, not mail as a tool.

02The honest cost comparison

Self-hosting is not free just because the software is. The infrastructure is modest; the operational commitment is the real cost. Someone has to patch, monitor queues, renew certificates, watch reputation and respond when mail stops flowing - and mail stopping is always urgent.

03What the suites are genuinely better at

Deliverability, without you thinking about it. Google and Microsoft have reputation that individual senders take months to build, and their outbound simply lands. That is the single biggest thing you take on when self-hosting, and the one most commonly under-estimated.

They are also better at the surrounding suite - calendar, documents, video, mobile device management, and the integrations everything else assumes. If you self-host mail you are choosing to solve those separately or accept a worse experience, and that decision affects more people than the IT team.

04What self-hosting requires you to get right

SPF, DKIM and DMARC configured and escalated to enforcement through monitoring rather than on day one. MTA-STS and correct reverse DNS. A staged warm-up plan so you build sending reputation gradually - launching at full volume is the most common cause of a new platform landing in spam.

Then the ongoing operations: outbound rate limiting and compromised-account detection, because one compromised mailbox sending spam can undo a year of reputation in a day. Inbound filtering tuned to your actual mail rather than defaults. And monitoring that tells you mail has stopped before your users do.

• SPF, DKIM, DMARC to p=reject via monitored escalation.
• MTA-STS, TLS-RPT and correct forward / reverse DNS.
• Staged volume warm-up on clean IP space.
• Outbound rate limits and abuse detection.
• Queue and reputation monitoring with alerting.

05The middle option most people miss

You do not have to choose one for everything. A common and sensible arrangement is a hosted suite for staff mailboxes, where the suite ecosystem matters, and self-hosted infrastructure for application and transactional mail, where volume economics and programmatic control matter.

This splits the problem along the line where the trade-offs actually differ. Your team keeps calendar and document integration; your product gets the mail control it needs; and your transactional volume does not sit on a licence priced per human.

06Migration is the part to plan for

Moving mailboxes is well-trodden - IMAP migration preserves folders, flags and dates, and can run incrementally so users work throughout. The parts that cause pain are calendar data, shared mailboxes, delegated access and forwarding rules, so inventory those before committing to a date.

Keep the old system reachable read-only for a period after cutover. The cost is small and it converts a category of migration incidents into a mild inconvenience, which is a trade worth making on a system as visible as email.