The self-hosted vs managed email infrastructure decision is one I have been asked to help organisations make dozens of times, and the answer is almost always more contextual than the organisations asking the question initially believe. The framing I usually encounter: "we are paying $X per month to Mailchimp/Klaviyo/Sendgrid and it feels like we could do this cheaper ourselves." That framing is sometimes correct and sometimes completely wrong, and the difference is entirely in the specifics of the organisation's situation, capabilities, and requirements.
I am going to give you the honest version of this analysis — including the cases where self-hosting is genuinely the right answer, the cases where it definitely is not, and the cases where a hybrid approach is better than a binary choice. I have operated self-hosted PowerMTA infrastructure at scale and managed ESPs for clients, and my opinions come from both sides of this question.
The Decision Framework: Five Questions That Determine the Answer
Before running the cost comparison, answer these five questions honestly. They often make the cost comparison irrelevant because they determine whether self-hosting is operationally feasible at all:
1. Do you have email infrastructure engineering expertise in-house? Self-hosting PowerMTA and MailWizz at production scale requires someone who understands Postfix or PowerMTA configuration, Linux server administration, DNS management (SPF, DKIM, DMARC), SMTP protocol behaviour, and deliverability fundamentals. This is not a skill set that most organisations have on staff outside of email-focused companies. If the answer is "we would need to hire or learn," factor in that cost — it is typically 3-6 months of engineering time to become competent in self-hosted email operations, and ongoing operations require 20-40 hours per month of experienced engineering time.
2. What happens to your business when email delivery fails? Self-hosted infrastructure has failure modes that managed ESPs handle for you — server outages, MTA configuration errors, blocklist incidents, IP reputation events. These require urgent response from engineering staff. A managed ESP has a support team whose job is resolving these incidents. If email delivery failure is operationally catastrophic and you do not have 24/7 on-call engineering capacity, the managed ESP's operational support justifies its premium over self-hosting even if the economics otherwise favour self-hosting.
3. Do you need capabilities that managed ESPs do not provide? Certain use cases are genuinely better served by self-hosted infrastructure: white-label email sending for clients (most ESPs prohibit or restrict this), very high volume with specific per-ISP routing requirements, unique delivery configurations that no ESP supports, or compliance requirements that prohibit storing email data on third-party infrastructure. If your use case has these characteristics, self-hosting may be the only viable option regardless of cost.
4. What is your monthly send volume? Self-hosting becomes cost-competitive with managed ESPs somewhere in the 5-15 million per month range, depending on which managed ESP you are comparing against. Below 1 million monthly, managed ESPs are almost always cheaper after accounting for server costs and engineering time. Above 20 million, self-hosting economics are compelling. In between, the comparison requires actual numbers.
5. Do you need deliverability isolation? Managed ESP shared pools mean your reputation is partially shared with other senders on the platform. Self-hosted dedicated IPs provide complete isolation — only your sending behaviour affects your reputation. If you are in a category where reputation isolation is critical (cold email operations, multi-client agency sending, high-volume promotional sending where one bad campaign could affect all others), self-hosting on dedicated IPs provides isolation that shared managed ESP pools cannot.
Cost Crossover: Where Self-Hosting Becomes Economically Justified
# Monthly cost comparison — self-hosted vs managed ESP # Assumptions: 10 million emails/month sending volume # SELF-HOSTED (PowerMTA + MailWizz stack): # Server (dedicated, 32GB RAM, SSD): $150/month # PowerMTA licence: $200/month (entry commercial) # IP addresses (10x /32 dedicated IPs): $50/month # IP warmup service (Mailreach, 10 mailboxes): $250/month # Monitoring tools: $50/month # TOTAL INFRASTRUCTURE: $700/month # # Engineering time (40 hrs/month @ $100/hr): $4,000/month # TOTAL SELF-HOSTED: $4,700/month # Per 1,000 emails: $0.47/1,000 # # Note: Engineering time is the largest cost and is real # even if the engineer is a salaried employee — opportunity cost counts # MANAGED ESP (Mailgun at 10M/month): # Mailgun Growth plan with volume discount: ~$700/month # No engineering time for infrastructure: $0 # TOTAL MANAGED: $700/month # Per 1,000 emails: $0.07/1,000 # At 10M/month, Mailgun is DRAMATICALLY cheaper including engineering time # The self-hosting cost advantage requires much higher volume OR # elimination of the engineering time cost (existing staff, no opportunity cost) # REVISED self-hosted calculation (existing engineer, no incremental cost): # Infrastructure only: $700/month # Per 1,000 emails: $0.07/1,000 # Now comparable to Mailgun — but engineering time was NOT eliminated, # just not explicitly counted # Realistic crossover WITHOUT engineering time counted: # Self-hosted infrastructure cost: $700/month fixed # Managed ESP at $0.50/1,000: $700 at 1.4M emails/month # At volumes above 1.4M/month, self-hosting is cheaper on infrastructure alone # # Realistic crossover WITH engineering time ($100/hr, 40 hrs/month): # Self-hosted total cost: $4,700/month # Managed ESP at $0.50/1,000: $4,700 at 9.4M emails/month # At volumes above 9.4M/month, self-hosting is cheaper total
The cost analysis reveals why "it must be cheaper to self-host" is often wrong: the engineering time to operate self-hosted infrastructure is the dominant cost, and it eliminates the cost advantage until volume is high enough to overcome it. The organisations for whom self-hosting is genuinely cost-justified are those sending at very high volumes (10M+ per month) with existing engineering staff who have capacity for infrastructure operations.
Deliverability: When Self-Hosting Wins and When It Doesn't
The deliverability comparison depends heavily on what kind of sending you are doing and what your current reputation situation is:
Self-hosted wins on deliverability when: You need complete reputation isolation — your email programme has characteristics that would be problematic on a shared ESP pool (high volume cold email, aggressive promotional patterns, industry-specific content that generates elevated complaint rates). Your sending patterns require per-ISP routing control that managed ESPs cannot provide. You need to send from a specific IP range or ASN for compliance reasons. You are managing email on behalf of multiple clients and need per-client IP pools with complete isolation between clients.
Managed ESP wins on deliverability when: You are starting a new sending programme — managed ESPs' warm, maintained shared pools give new programmes immediate good inbox placement without the 8-12 week IP warmup period self-hosting requires. Your volume is below 1-2 million per month — dedicated IPs at this volume do not have enough history to perform as well as a managed ESP's well-maintained pool. You have had a reputation incident and need to recover — moving to a managed ESP gives you access to their established pool reputation while your programme recovers, faster than rebuilding on self-hosted dedicated IPs. You do not have deliverability monitoring expertise — managed ESPs' support teams catch and resolve reputation incidents that self-hosted operators miss because they are not monitoring the right signals.
Operational Requirements: What Self-Hosting Actually Demands
The operational requirements that organisations planning to self-host consistently underestimate:
Daily operations (20-30 min/day): Checking MTA accounting logs for delivery anomalies; reviewing deferred queue size and composition; monitoring SNDS data for Microsoft reputation; checking Gmail Postmaster Tools domain reputation; verifying blocklist clean status for all sending IPs. This is the maintenance routine that catches problems before they become incidents. It requires someone who knows what "normal" looks like for the specific installation — which takes 2-3 months to calibrate on a new installation.
Incident response: Self-hosted email has incidents — an IP gets listed in Spamhaus, a configuration change breaks DKIM, a campaign generates a complaint spike that damages domain reputation, a server hardware failure interrupts sending. Each of these requires engineering response within hours, not business days. The incident response capacity must exist before the first incident, not after — the first time your team encounters a Spamhaus SBL listing or a Microsoft SNDS Red status is not the time to be researching how to respond.
Software maintenance: PowerMTA and MailWizz release updates that address security vulnerabilities, add ISP-specific traffic shaping rules, and fix bugs. Keeping the installation current requires regular update cycles — typically 4-6 times per year for minor updates, annually for major version upgrades. Updates require testing before production deployment and rollback planning when something goes wrong.
ISP relationship management: At high volume, maintaining good reputation at Microsoft, Yahoo, and Gmail requires deliberate management — monitoring their feedback systems, responding to specific delist or feedback requests, and sometimes engaging directly with ISP postmaster teams. Managed ESPs handle these relationships on behalf of their customers through dedicated deliverability teams. Self-hosted operators handle them independently or not at all.
Self-Hosted Stack Options: PowerMTA, Postal, and Alternatives
PowerMTA + MailWizz (commercial, industry standard): PowerMTA is the commercial MTA of choice for high-volume sending operations — ESPs, deliverability agencies, and large-brand email programmes. VMTA architecture, per-ISP traffic shaping, detailed accounting logs, and excellent ISP relationship tools. MailWizz provides the campaign management, list management, and subscriber interface layer that PowerMTA lacks. Combined, they form the industry-standard self-hosted email marketing stack. Cost: PowerMTA entry commercial licence ~$200/month + MailWizz one-time or subscription. The stack documented throughout this site.
Postal (open source, free): Postal is an open-source email server with MTA and campaign management features. Free to deploy, requires Linux server and engineering expertise to configure and operate. Significantly less capable than PowerMTA in terms of per-ISP routing, traffic shaping, and deliverability tooling, but adequate for moderate-volume programmes that cannot justify PowerMTA licensing costs. Best for: e-mail operations under 500k/month where deliverability sophistication requirements are modest.
ListMonk (open source, transactional + marketing): A newer, simpler open-source alternative that pairs with Postfix or Amazon SES for SMTP delivery. Less feature-complete than MailWizz for complex marketing automation but significantly easier to deploy and operate. Good for technically capable teams that want self-hosted control without PowerMTA complexity.
Postfix + mailing list software (open source, flexible): For specific use cases — academic mailing lists, internal distribution lists, research communications — Postfix with Mailman or Sympa provides adequate capability at minimal software cost. Not appropriate for commercial marketing email at scale.
Managed ESP Landscape: What You Are Actually Buying
Beyond the per-email pricing, managed ESPs provide several operational services that self-hosting requires you to build or forgo:
Deliverability management: ESP deliverability teams monitor pool reputation, maintain FBL enrollments, respond to ISP postmaster requests, and manage blocklist incidents. For most senders, this is the most valuable part of the managed ESP value proposition — operational expertise applied continuously to a complex technical domain.
ISP relationships: Major ESPs have established relationships with Gmail, Yahoo, and Microsoft postmaster teams. These relationships provide access to escalation paths when automated systems create problems that require human intervention — access that individual self-hosted operators typically do not have.
Compliance infrastructure: List-Unsubscribe header management, MAGY compliance monitoring, CAN-SPAM compliance tools — managed ESPs handle these systematically. Self-hosted operators must implement these independently.
Support: When something goes wrong with a managed ESP, there is a support team. When something goes wrong with self-hosted infrastructure, there is the internet and your own expertise. The quality of that expertise — and the hours available to apply it during an incident — is the risk the self-hosted operator accepts in exchange for the cost savings.
Hybrid Architecture: When You Need Both
The hybrid approach — self-hosted infrastructure for high-volume promotional email, managed ESP for transactional email — is increasingly the right answer for organisations above the 5M/month threshold. The logic: self-hosted PowerMTA provides the volume economics and reputation isolation for marketing campaigns; managed Postmark or Mailgun transactional provides the reliability, diagnostics, and support needed for order confirmations, password resets, and other time-sensitive expected email.
This separation is the same stream separation that the transactional guides on this site recommend for all senders above moderate volume — self-hosting just makes it more explicit, because the self-hosted promotional infrastructure and the managed transactional ESP are genuinely separate systems with no possibility of reputation crosstalk. The operational cost is managing two email systems rather than one, but each system is optimised for its specific use case rather than being a compromise across both.
Migration Considerations: Going From Managed to Self-Hosted
Migrating from a managed ESP to self-hosted infrastructure is a 3-6 month project for organisations doing it for the first time. The migration sequence that minimises delivery disruption:
(1) Deploy and configure the self-hosted stack in parallel with the managed ESP — do not decommission the managed ESP until the self-hosted stack is proven. (2) Warm up the self-hosted IPs while continuing to send production volume through the managed ESP — this builds IP reputation without risking production delivery. (3) Begin routing low-sensitivity traffic (newsletters to highly engaged subscribers, internal communications) through the self-hosted stack while monitoring delivery rates and reputation signals. (4) Gradually increase the fraction of production traffic on self-hosted over 8-12 weeks until the self-hosted stack is handling full production volume. (5) Maintain the managed ESP account for 30-60 days after the full migration as a failover option before decommissioning.
The migration that skips steps 2-4 — standing up self-hosted infrastructure and routing full production volume to it immediately — is the migration that generates the horror stories about self-hosting breaking deliverability. Unwarmed IPs, untested configurations, and unproven operational procedures applied to production traffic create exactly the conditions for the catastrophic inbox placement failures that discourage organisations from self-hosting. The gradual migration is not optional risk management; it is the only approach that consistently produces successful outcomes.