ESP to Self-Hosted Migration

There is a particular pitch that recurs every year: stop paying your ESP, install Postfix on a $5 VPS, and send email for almost nothing. The software really is free and really does work — but the $5 figure is the sticker price on a much larger bill, and the part that actually breaks, deliverability, has gotten dramatically harder since late 2025. Moving off an ESP to self-hosted can be a genuinely good decision, or an expensive lesson, depending entirely on your volume, your skills, and your honesty about the real cost. This page lays out that real cost, the rising deliverability bar, when self-hosting makes sense — and the third option that gets you most of the upside without the ops tax.

Why move off an ESP to self-hosted?

The motivations are real, which is why the question keeps coming up. Cost is the obvious one: at scale, per-email ESP pricing becomes expensive, and a flat-cost server you run yourself can be ten to twenty-five times cheaper on infrastructure alone at high volume. Control is the second: your own server is infinitely configurable in ways a managed platform is not, with no sending limits imposed from outside and no per-feature gating. Sovereignty is the third and increasingly the strongest: your data stays on your infrastructure, under your jurisdiction, processed only by software you control, with no sub-processors and no cross-border transfers — which for legal firms, healthcare, and investigative journalism is closer to a regulatory requirement than a preference. And there is independence: no third party can change your pricing, suspend your account, or deprecate a feature you depend on. These are sound reasons. The mistake is assuming they come for the price of a small VPS, when in fact they come with an operational commitment that the rest of this page is about being honest about.

Is self-hosted email actually cheaper?

On the raw infrastructure line, dramatically — and on the honest all-in number, often not, unless certain conditions hold. The VPS is $5–20 per month, the software is free, and TLS is free, which is where most “self-host for $5” articles stop. The true cost of ownership adds the parts those articles omit: your time at one to four hours per month, a learning curve of twenty to forty hours up front, unpredictable incident response when an IP is blacklisted or a reputation needs rebuilding, monitoring tools, and backup infrastructure. Counted honestly, that lands most operators at roughly $100–500 per month all in. The break-even against an ESP sits around $50 per month in ESP spend, and self-hosting wins clearly at high volume — at 1M+ emails per month, even several hundred dollars of time cost leaves you well ahead of the $500-plus an ESP would charge. Below roughly 200K per month with no existing technical staff, the maintenance time costs more than the ESP did. The savings are genuine at scale; the framing that self-hosting is nearly free is not. Honest accounting is the whole point.

The software is the easy part

A reassuring and slightly dangerous truth about self-hosting is that the software works and is not the obstacle. Postfix is the battle-tested standard MTA; Postal is purpose-built for sending at volume; Mailcow bundles Postfix, Dovecot, Rspamd filtering, and a clean admin UI in Docker. Any of them will get a correctly configured server sending and receiving in a few hours to a couple of days. The danger is mistaking that for the job being done. As the practitioners who run these systems put it, the setup is not the hard part — ongoing maintenance and deliverability management is where the real effort lives. Once the server is up, the actual work begins: protecting IP reputation, reading logs when delivery drops, chasing DKIM alignment failures, remediating blacklist entries, applying security patches so your server does not become an open relay, and watching DMARC reports. The software solves the mechanics of sending a message. It does not solve the problem of that message being trusted, and trust is the entire game.

Why is the deliverability bar higher now?

Because the major inbox providers moved from gentle filtering to hard rejection, and that changes everything for a self-hosted sender. In late 2025, Gmail began rejecting non-compliant mail at the SMTP level — permanent 550 5.7.26 bounces for authentication failures — rather than quietly routing it to spam, and Microsoft and Yahoo aligned with their own rejections, including 550 5.7.515 codes for senders without proper authentication. The consequence is stark: if your email cannot prove its identity through SPF, DKIM, and DMARC, it does not reach the spam folder, it does not get delivered at all. For a self-hosted server this makes SPF, DKIM, DMARC, correct PTR records, TLS, and a clean IP reputation the non-optional table stakes for delivering anything. And a subtle failure is the dangerous kind: an SPF record that passes but does not align with your From header, or a DKIM key that was rotated without updating DNS, will silently bounce legitimate mail for days before anyone notices. The bar for self-hosting has never been higher, which is why the casual “just install Postfix and point your MX” era is genuinely over.

No support, no guardrails

Two things you lose leaving an ESP rarely show up on the cost comparison, and both matter. The first is support: there is no team to call when delivery breaks. A blacklisted IP means your mail stops delivering until you personally diagnose the cause, fix it, request delisting, and wait — some blocklists take a day or two, some take weeks, and a seriously damaged reputation can take a month of careful low-volume sending to rebuild. Every incident is your problem, on your timeline. The second is guardrails. A managed platform quietly protects you from yourself: automated throttling, reputation-protection systems, and sending limits that stop you from nuking your own deliverability. A self-hosted server has none of that unless you build it. Send too fast before an IP is warmed, hit a spam trap from an unclean list, or forget DMARC on a new domain, and you are blacklisted with no system catching the mistake before it lands. For a team with the expertise to be its own safety net, that freedom is fine. For a team without it, the absence of guardrails is how self-hosting goes wrong fastest.

When does self-hosting genuinely make sense?

It makes sense when several specific conditions line up, and the honest reality is that they often do not. The strongest cases are: very high volume, where the savings dwarf the time cost — at 1M+ emails per month you are ahead even with significant labour; an existing sysadmin who can absorb maintenance into work they are already paid for, which drives the marginal time cost toward zero; a hard control requirement no ESP can meet; running many domains, where an agency with twenty-plus client domains saves enormously on a single instance; and a genuine data-sovereignty or privacy requirement — legal, healthcare, investigative journalism — where keeping data on your own infrastructure under your jurisdiction with the shortest possible processor chain is a practical regulatory need rather than a preference. There is also a legitimate non-financial reason: some people find email infrastructure genuinely interesting and want the control, and that is valid. Outside these cases, the maintenance time tends to exceed the savings, and a managed option is the more rational call.

The third option: managed dedicated infrastructure

Most discussions frame the choice as a binary — convenient ESP on a shared pool you do not control, or full self-hosting where you own everything and run everything. There is a third option that captures much of what people actually want from self-hosting without the ops tax: managed dedicated infrastructure. You get the dedicated IPs and the control that distinguish self-hosting from a shared ESP — your own reputation, your own sending, configurability — while the provider carries the operational burden: warming, deliverability monitoring, blacklist remediation, security patching, backups, and the guardrails that stop you damaging your own reputation. It is the ownership and cost-predictability of self-hosting with the support and safety net of a managed service. For the many teams whose real goal is owned IPs and a jurisdiction they control — not the hobby of running a mail server — this is the rational middle. Pure self-hosting still wins when you have a sysadmin to absorb the work or an absolute, no-sub-processors sovereignty requirement; managed dedicated wins when you want the control but not the second job.

What carries over when you leave an ESP

The reputation split governs the pacing, as in any migration. Your domain reputation carries over — it is tied to your sending domain, so the trust your domain has built travels with you. Your ESP’s IP reputation does not: shared-pool reputation belonged to the pool, and even a dedicated ESP IP stays with the ESP, so your new infrastructure starts warming from zero. There is a sharp ESP-specific trap: if your ESP signed your mail with its own DKIM domain rather than yours — common with some marketing platforms — your historical reputation was building on their domain, and on your own domain you effectively start fresh. And your suppression list only carries over if you export it before you leave, which is both a deliverability necessity and a compliance one. Knowing what transfers and what is rebuilt is what keeps the timeline and the expectations honest.

How the migration actually runs

Leaving an ESP for self-hosted or managed dedicated infrastructure follows the same disciplined pattern as any infrastructure migration. You keep the ESP live throughout as your fallback — never cancel on day one. You stand up the new infrastructure with SPF, DKIM and DMARC configured and verified before a single send, holding DMARC at p=none through the transition. You export your suppression data and load it first, so opt-outs survive. Then you warm the new IPs on a proper two-to-four-week ramp, starting with your most engaged recipients at low volume, shifting traffic from the ESP gradually while watching reputation on both sides. Only once the new infrastructure is stable do you decommission the ESP. The difference between self-hosted and managed dedicated is not the migration steps — those are identical — but who executes and owns them afterward: with self-hosting, you; with managed dedicated, us. Either way, rushing the warm-up is the single most common cause of a post-migration crash.

How we run it

With MCSNET, you do not have to choose between a shared ESP pool and becoming your own ops department. We run managed dedicated Canadian infrastructure in Toronto, so you get owned dedicated IPs, control, and PIPEDA residency, while we carry the operations that sink most self-hosting attempts. We migrate you as a parallel project: keep your ESP live as a fallback, stand up your dedicated IPs with authentication configured and verified, export and load your suppression, warm the new IPs from your most engaged recipients, and shift traffic gradually while watching reputation on both sides. Afterward, we own the warming, the monitoring, the blacklist remediation, the patching, and the guardrails — the parts that, self-hosted, would be your nights and weekends. And if your real need is sovereignty over your inboxes specifically, we can run the outbound side of a hybrid where you self-host receiving and we handle sending. We will tell you honestly when pure self-hosting is the better fit — a sysadmin on staff, an absolute no-sub-processor requirement — but if you want the control without the second job, this is it.

# self-hosted vs managed dedicated · honest cost · brand.ca
vps           $5–20/mo  sticker price only
true all-in   $100–500/mo  (time · monitoring · backups · incidents)
break-even    ~$50/mo esp spend · clear win at 1M+/mo
auth bar      spf+dkim+dmarc table stakes · 550 reject if missing
guardrails    self-host: none · managed: built in
blacklist     self-host: your problem · managed: we remediate
managed ded   owned ips + control + residency · ops on us

Why work with us?

Because we offer the honest third option and the honest advice that comes with it. Plenty of guides will sell you the $5 self-hosted dream without the $100–500 reality; plenty of ESPs will sell you convenience on a shared pool you do not control. We do neither. We run managed dedicated Canadian infrastructure that gives you the ownership, control and sovereignty people want from self-hosting, with the operational burden — warming, monitoring, blacklist response, patching, guardrails — carried by us, and PIPEDA residency built in. We will tell you plainly when self-hosting genuinely suits you and when it does not, because the goal is the right infrastructure for your situation, not a sale. If you want owned IPs and a jurisdiction you control without running a mail server as a second job, the migration onto managed dedicated infrastructure is exactly what we do.

Who this is for, and who it is not

It is for teams drawn to self-hosting for the control, ownership, cost or sovereignty — but who do not have, or do not want to dedicate, the staff time to run mail infrastructure and be their own deliverability and security team. It is for organizations with a real sovereignty or residency need that want owned IPs and Canadian jurisdiction without the operational burden, and for those weighing a hybrid where they self-host receiving and offload sending. It is explicitly not for the team with a capable sysadmin to absorb the work, an absolute no-sub-processor requirement, or a genuine enjoyment of running their own server — for them, pure self-hosting is a sound choice and we will say so. And it is not a way to escape IP warming or the rising authentication bar; nothing is. This sits alongside the broader infrastructure migration discipline and the SES migration that shares its “stop being your own ops team” logic, landing on managed dedicated Canadian infrastructure run on a real MTA. The choice is not really ESP versus self-hosting — it is finding the point on that spectrum that fits your team, and for many, managed dedicated is it.