--- title: Should You Still Run Your Own Mail Server? description: Mail is really three jobs, not one. Here is how I separate them, what self-hosting actually costs now, and when running your own server still holds up. date: 2026-09-16 updated: 2026-09-16 tags: [hosting, infrastructure, decision frameworks] url: "https://joshdargie.com/blog/should-you-run-your-own-mail-server" author: Josh Dargie --- Every few months someone asks me whether they should still be running their own mail server. It rarely arrives as its own project. It comes up in the middle of something else: a hosting migration, a cost review, or a box that is three operating system versions behind and nobody wants to be the one to touch it. It is a fair question. The answer is almost never a plain yes or no, because "mail" is at least three separate jobs, and most of the regret I see comes from treating them as one. I should declare the bias up front: my hosting company, [DrivenHost](https://drivenhost.com), hosts mail for customers. I still tell people to leave mail where it is more often than you would expect. ## Split the question into three Staff mailboxes are the first job. People logging in, sending and receiving, keeping years of history they will eventually need for a dispute or an audit. Application mail is the second. Password resets, receipts, invoices, shipping notices, alerts from your monitoring. Low volume per message, very high consequence when it stops. Inbound plumbing is the third. Aliases, catch-alls, forwarders, the address your ticketing system reads, the old app that still collects mail from a POP box. This is usually the real reason the old server is still running, and usually nobody has looked at it in years. Almost no small or mid-size business should be self-hosting the first category in 2026. The second has a defensible case at volume. The third is where the landmines are. ## The bar moved, and it moved recently Running a mail server used to mean keeping the software patched and staying off blocklists. That is no longer the job. Since early 2024, Google and Yahoo have required bulk senders to authenticate with SPF and DKIM, publish a DMARC record with alignment, offer one-click unsubscribe on marketing mail, and keep spam complaints well under 0.3 percent. Microsoft brought in comparable rules for Outlook.com in May 2025. The published thresholds start around 5,000 messages a day to a given provider, but the requirements have effectively become the floor for everyone, because filtering is reputation-based and the reputation of a small sender is thin to begin with. So self-hosting now means owning IP reputation, DNS records that must stay correct forever, TLS certificates, feedback loops, and a bounce and complaint process. None of that is difficult. All of it is ongoing, and all of it fails quietly. That last part is what I want people to sit with. A mail server is one of the few remaining systems that can break in a way nobody reports. Your invoices land in junk for six weeks and the first symptom is your receivables ageing. ## What it actually costs The cost is not licences. It is attention, spread thin across a year. Patching and version upgrades. Certificate renewals. Watching blocklists and reading DMARC reports. Handling the week your IP gets flagged because a customer's account was compromised and used to send from your server. Answering "did this go out?" questions with evidence rather than a guess. Backups you have actually restored, which is a different thing from backups you have configured. If you cost that honestly at a loaded hourly rate, self-hosting mailboxes for a team of twenty is almost never cheaper than paying for hosted mailboxes, which typically run in the range of $8–12 CAD per user per month for a business plan. The arithmetic only turns when volume is large enough that per-message or per-seat pricing dominates, and by then you usually have a person whose job title includes deliverability. ## When self-hosting still holds up There are real cases. High-volume outbound where per-message pricing is the largest line on the bill. Data residency or retention obligations that are written down somewhere rather than assumed. A product where mail handling is the product. Staffing that already includes someone who does this work deliberately, not someone who inherited it. Be careful with that last one. "We have a guy" is a staffing plan right up until the guy leaves, and mail is unusually good at revealing who really held the keys. If that phrase describes your setup, the related problem is probably [who owns your domains and accounts](/blog/who-owns-your-business-accounts) rather than the server itself. ## Do the inventory before the decision Before anyone prices a migration, answer one question: what sends mail on your behalf today, from which domains, and who notices when it stops? Most organisations cannot answer that. There is a CRM, a payroll system, an e-commerce plugin, a form on the website, a monitoring tool, and something a former employee set up in 2019. Your DMARC aggregate reports will show you most of them, including the ones you have forgotten. Get that list first. It turns the decision from a philosophical one into a cost comparison, and it is also the single best way to keep a mail move from going sideways later, which is a pattern I have written about in [why migrations go wrong](/blog/migrations-go-wrong). Then decide per category. Mailboxes hosted, application mail through a sending service or your own relay depending on volume, plumbing consolidated and documented. Splitting it that way is usually cheaper and always calmer than one big rebuild. If you want an outside read on your current setup before you commit to a migration, that is the kind of work I do on a fixed-fee or hourly basis. My [hosting and platform work](/hire#hosting) is where that sits, or just [get in touch](/contact) and describe what you are running. ## Sources - [Email sender guidelines - Gmail Help](https://support.google.com/mail/answer/81126?hl=en) - [Email sender guidelines FAQ - Gmail Help](https://support.google.com/a/answer/14229414?hl=en) - [Outlook's new requirements for high-volume senders - Microsoft](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) - [Yahoo Sender Hub best practices](https://senders.yahooinc.com/best-practices/)