- August 2022
- Engineering Memo · External Release
Every organisation sending email at volume eventually faces a build-vs-buy decision: should we manage our own email infrastructure, purchase a managed service, or continue on a shared ESP? This decision is frequently made on incomplete information — comparing only the direct costs without accounting for operational burden, capability constraints, and the performance differences between models that translate into revenue impact.
This note provides a framework for making this decision with complete information, covering the full cost structure of each model, the operational requirements that determine whether each model is viable for a specific organisation, and the capability differences that affect deliverability and programme performance.
Three Models, Three Cost Structures
Self-built dedicated infrastructure has the most complex economics: capital costs (server hardware or VPS provisioning), recurring costs (hosting, IP allocation, MTA licensing), and operational costs (engineering time for setup, ongoing management, incident response). The engineering cost is the most underestimated element — a PowerMTA deployment that is correctly configured and actively managed requires roughly 10–20 hours per month of skilled email infrastructure engineering time for monitoring, tuning, and incident response. At a loaded engineering rate of €80–€120 per hour, this represents €800–€2,400 per month in operational cost before any infrastructure fees. Programmes with in-house email infrastructure expertise may perform this work at lower marginal cost; programmes that require contractor or specialist support may pay premium rates.
Managed dedicated infrastructure bundles the infrastructure, MTA software, and ongoing management into a monthly service fee. The operator receives the operational benefits of dedicated infrastructure — isolated IPs, full accounting log access, per-ISP configuration control — without the full operational burden. The service provider handles monitoring, incident response, configuration tuning, and ISP relationship management. The monthly cost (€490–€1,890 depending on volume and configuration) is predictable and includes the operational value that would cost €800–€2,400 per month to replicate in-house. For most programmes without specialist email infrastructure expertise, managed infrastructure produces better deliverability outcomes than self-built at lower total cost.
Shared ESP has the simplest cost structure: per-message pricing with no infrastructure setup cost, no operational burden, and managed deliverability included. The per-message price appears high compared to the marginal cost of dedicated infrastructure sends, but this premium includes the operational value of the ESP's deliverability management, which has real cost. The ESP model becomes economically inefficient above a volume threshold where the per-message cost exceeds the equivalent managed infrastructure cost — typically around 300,000–600,000 messages per month as documented in the scaling note.
Figure 1 — Monthly Total Cost of Ownership by Volume and Model
The Hidden Costs That Change the Calculation
The cost comparison often focuses on the visible line items — per-message ESP pricing vs managed service monthly fee vs server cost. The hidden costs that change the calculation are operational burden and performance gap.
Operational burden is the engineering time required to keep the infrastructure performing at its capability level. Self-built infrastructure with no ongoing management investment delivers degrading performance over time — configurations drift, warmup schedules are not followed, bounce processing falls behind, and monitoring alerts go uninvestigated. The engineering cost of preventing this degradation is the true operational cost of self-built infrastructure. Many organisations underestimate this cost because the degradation is gradual and doesn't produce a single visible incident — it produces a slow decline in inbox placement that is often attributed to "industry changes" rather than maintenance deficit.
Performance gap is the revenue difference between what the infrastructure delivers and what it could deliver if correctly maintained. A self-built infrastructure with maintenance deficit may deliver 68% inbox placement where correctly maintained dedicated infrastructure would deliver 78% — a 10-point gap that translates to approximately 8% fewer campaign clicks, which translates to 8% lower campaign revenue. At €200,000 per year in email-attributed revenue, this 8% gap represents €16,000 per year in foregone revenue. The performance gap cost is real but invisible in the monthly cost comparison — it doesn't appear as a line item, only as slightly lower open rates and slightly lower conversion rates that are attributed to other causes.
Including both the operational burden cost and the performance gap cost produces a materially different cost comparison than the direct cost analysis. For organisations that accurately estimate their engineering operational cost and honestly assess their deliverability performance against properly managed infrastructure, the managed infrastructure model typically produces lower total cost of ownership than self-built for programmes without dedicated in-house email infrastructure expertise.
Decision Framework: Which Model Fits Which Organisation
The correct model depends on the intersection of three factors: volume, expertise, and control requirements.
Low volume (under 300K messages/month) + any expertise level: Shared ESP. The economics clearly favour ESP at this volume. The operational simplicity allows the email team to focus on content and programme strategy rather than infrastructure. Exception: if the programme has specific data residency requirements that the available ESPs cannot meet, or specific ISP configuration requirements that shared infrastructure cannot provide, dedicated infrastructure may be appropriate even at lower volumes.
Medium volume (300K–1M messages/month) + no in-house email infrastructure expertise: Managed dedicated infrastructure. The economics are competitive with shared ESP in this range, and the isolation, visibility, and configuration control advantages of dedicated infrastructure produce deliverability performance that shared infrastructure cannot match. The managed service provides the operational expertise without requiring in-house hiring.
High volume (1M+ messages/month) + dedicated email infrastructure team in-house: Self-built infrastructure. At this volume, the economics of self-built are compelling, and the team has the expertise to operate it correctly. The investment in a dedicated team pays back in the configuration flexibility and operational control that produces elite deliverability outcomes at scale.
High volume + no dedicated email infrastructure expertise: Managed dedicated infrastructure, evaluated quarterly for in-house build. Many organisations at this scale underestimate the specialised expertise required to operate email infrastructure correctly and would be better served by managed infrastructure while developing in-house expertise, rather than building in-house immediately and accepting the performance degradation that accompanies the learning curve.
Table 1 — Build vs buy vs managed: decision matrix
| Criterion | Shared ESP | Managed dedicated | Self-built |
|---|---|---|---|
| Setup time | Hours | Days to weeks | Weeks to months |
| IP isolation | Shared (co-tenant risk) | Full | Full |
| MTA-level control | None | Via service provider | Complete |
| Economics (500K+/mo) | Expensive per-message | Competitive fixed cost | Lowest marginal cost |
| Expertise required | Low | Low (provider manages) | High (in-house) |
Making the Transition: From Shared to Managed
The most common transition for growing programmes is from shared ESP to managed dedicated infrastructure. This transition introduces new operational requirements — managing the relationship with the infrastructure provider, understanding the deliverability reports that the provider surfaces, and making the programme decisions (list hygiene, frequency management, segment selection) that the infrastructure provider cannot make on the programme's behalf.
The programme's responsibilities in a managed infrastructure relationship: list hygiene and engagement-based segmentation (the programme team controls who receives each campaign and with what frequency); FBL complaint processing action (the provider processes FBL data, but decisions about which acquisition sources to suspend or which list segments to suppress require programme-level authority); campaign review (the provider can flag campaigns with content patterns that may affect deliverability, but content decisions remain with the programme team); and escalation response (when an ISP-level incident requires business decisions — pausing a campaign, stopping sends to an ISP — the programme team must be available to make those decisions promptly).
The distinction between what the managed infrastructure provider manages and what the programme team manages is the clearest division of responsibility in the managed model: the provider manages the infrastructure (configuration, IPs, monitoring, incident response, ISP relationships); the programme team manages the programme (lists, content, frequency, segmentation). Neither party can compensate for the other's failures — excellent infrastructure with poor list management produces poor deliverability; excellent list management on poorly managed infrastructure produces the same. The managed model works best when both sides perform their responsibilities at a high standard.
Quantifying the Deliverability Performance Gap Between Models
The performance gap between correctly managed dedicated infrastructure and a well-run shared ESP at equivalent volume can be quantified through the specific mechanisms that dedicated infrastructure provides but shared infrastructure structurally cannot. The three primary performance drivers:
IP reputation isolation. On dedicated infrastructure, the sending IP pool's reputation reflects only the programme's own sending history. No co-tenant complaint rate, bounce rate, or spam trap hit affects the reputation. On a shared ESP, even if the programme's own practices are excellent, a period of elevated co-tenant complaints can temporarily suppress the shared pool's reputation and the individual programme's inbox placement. The frequency and magnitude of this co-tenant contamination depends on the ESP's pool management — good ESPs manage it actively, but cannot eliminate it entirely. Dedicated infrastructure eliminates it structurally.
Per-ISP configuration control. Dedicated infrastructure allows tuning each ISP's domain block settings to the programme's specific reputation level and sending volume at that ISP. A programme with excellent Gmail reputation but moderate Yahoo reputation can configure different retry intervals, connection limits, and message rates for each ISP. Shared ESP domain blocks are configured for the aggregate of all their customers, not for the individual programme's ISP-specific reputation profile. This means shared infrastructure either over-sends to ISPs where the pool's reputation supports higher rates (wasting the reputation advantage) or under-sends where the individual programme's reputation would support higher rates (missing throughput that the reputation has earned).
Queue management transparency. On dedicated infrastructure, the accounting log shows exactly which messages are queued, for how long, at which ISP, with which response code. The programme can see immediately when a deferral accumulation at a specific ISP indicates a developing reputation problem, and respond before it becomes significant. On a shared ESP, queue state is typically invisible to individual customers — the platform manages queuing globally, and individual programmes see aggregate delivery rate reporting that lags the actual queue state by hours to days.
The revenue impact of these performance differences varies by programme, but a reasonable estimate for the inbox placement improvement from correctly managed dedicated infrastructure over a well-run shared ESP for a mature programme is 5–12 percentage points. At the revenue calculation from the inbox placement note (approximately €7,000 per year per percentage point improvement for a 400,000-contact programme), the 5–12 point improvement represents €35,000–€84,000 per year in additional email-attributed revenue. Against a managed infrastructure cost of €990–€1,890 per month (€11,880–€22,680 per year), the revenue improvement substantially exceeds the infrastructure cost even at the conservative end of the performance gap estimate.
The Opportunity Cost of Delayed Migration
Organisations that know they should migrate to dedicated infrastructure but delay the decision accumulate an opportunity cost from each month they remain on the suboptimal model. For a programme at 1 million messages per month paying €1.00/1,000 on a shared ESP (€1,000/month) when managed infrastructure would cost €990/month and produce 8% more inbox-delivered messages at equivalent list quality — the delay cost is real and compounding.
The direct cost saving from migrating (€10/month at this example) is trivially small, but the performance benefit — 80,000 additional messages reaching the inbox per month, at a 2% click rate and 3% purchase conversion at €50 AOV — represents approximately €2,400 per month in additional revenue. The monthly cost of delay is approximately €2,400 in foregone revenue per month, or €28,800 per year. The migration itself (4–8 weeks of dual-platform overlap and warmup) costs approximately €2,000–€4,000 in overlap operational costs. The payback period for executing the migration is 3–7 weeks.
The framing that makes delay attractive — "we'll migrate when things are less busy," "we'll do it after the next campaign," "we'll wait until next quarter" — produces a permanent delay that costs roughly €2,400/month for every month it continues. At the end of a year of delays, the cumulative cost is €28,800 plus the lost compounding reputation advantage that managed dedicated infrastructure would have been building during that year. The migration is rarely convenient; it is rarely as disruptive as anticipated; and the cost of delay consistently exceeds the cost of execution.
The In-House Build Decision: Realistic Requirements
Self-built email infrastructure is the appropriate choice for organisations with both the volume to justify it (1M+ messages/month) and the in-house technical expertise to operate it correctly. The expertise requirement is specific: email deliverability knowledge (not just general networking or Linux administration), PowerMTA configuration expertise, SMTP protocol fluency at the diagnostic level, and the operational discipline to maintain monitoring, review weekly reporting, and respond to deliverability incidents outside normal business hours when they occur at campaign send time.
Finding engineers with this specific expertise is difficult — the email infrastructure skill set sits at the intersection of networking, Linux systems administration, and specialised email deliverability knowledge that is not taught in university programmes and is rarely encountered in general IT hiring. Most organisations that self-build email infrastructure without this expertise end up with a partially correct configuration that works adequately until a problem occurs, at which point the diagnostic and remediation capability is insufficient and the organisation either hires outside expertise (at premium rates for urgent incident response) or accepts prolonged delivery problems while the team learns on the job.
The realistic assessment of in-house email infrastructure readiness should answer: does the team understand the SMTP-layer difference between a 421 deferral from Gmail and a 550 permanent failure? Can someone on the team read a PowerMTA accounting log and diagnose a per-ISP delivery rate problem from the per-domain block statistics? Does anyone understand the feedback loop between complaint rate and Gmail domain reputation and know how to respond to a reputation tier change in Postmaster Tools? If the honest answer to any of these questions is "no," the in-house self-build model will produce infrastructure that underperforms its potential — and the gap between potential and actual performance is the hidden cost that makes managed infrastructure the economically rational choice for organisations without this specific expertise already present in the team.
The build-vs-buy-vs-managed decision is ultimately a question about where specialist expertise resides — in your team, in a managed service provider, or in the combined experience of an ESP's platform. The correct answer varies by organisation. The incorrect approach is to make the decision based only on visible per-unit cost comparisons without accounting for the operational burden, performance gap, and expertise requirements that determine the total cost of each model. Organisations that use the complete framework — visible costs plus operational burden plus performance gap plus expertise requirements — consistently make the decision that produces the best commercial outcome for their specific programme at its specific scale and capability level.
Total Cost of Ownership: A Worked Example
To make the cost comparison concrete, consider an e-commerce programme sending 1.5 million messages per month with a 40% Gmail audience, 25% Yahoo, 20% Microsoft, and 15% other. Current configuration: shared ESP at €0.90 per 1,000 messages = €1,350/month. Current Postmaster Tools domain reputation: Medium. Estimated inbox placement: 75%.
Shared ESP cost: €1,350/month (direct cost). Estimated operational cost: minimal (ESP manages infrastructure). Total visible cost: €1,350/month. Hidden cost: the performance gap between Medium reputation on shared infrastructure and High reputation on dedicated. Estimated 8-point inbox placement difference × revenue impact = approximately €2,100/month in foregone revenue. Total cost including performance gap: approximately €3,450/month.
Managed dedicated infrastructure cost: €990–€1,490/month (service fee for 1.5M messages). Estimated inbox placement after 6 months of clean dedicated sending: 83% (8-point improvement over shared ESP baseline). Revenue impact: additional €2,100/month from improved placement. Net cost (service fee minus performance improvement value): €990–€1,490 minus €2,100 = effectively negative in terms of net economic impact — the service fee is more than offset by the performance improvement. True comparable cost: approximately €990–€1,490/month with better performance vs €1,350/month with lower performance.
Self-built infrastructure cost: Infrastructure fees approximately €400–€600/month (server, IPs, MTA license). Engineering operational cost: 15 hours/month × €100/hour = €1,500/month. Total: €1,900–€2,100/month. If operated correctly with appropriate expertise, performance equivalent to managed service. If operated with expertise deficit, performance worse than managed service at higher total cost — the common outcome for programmes that self-build without the required specialist knowledge.
The worked example illustrates why infrastructure model decisions made on visible cost alone systematically underestimate the value of managed dedicated infrastructure and overestimate the attractiveness of self-building. Including the performance gap cost in the comparison — which requires honestly assessing the current inbox placement shortfall attributable to shared infrastructure constraints or self-build management deficit — consistently narrows the apparent economic gap and often reverses the direction of the comparison. The full economics favour the model that produces the best programme outcomes, not the lowest line-item infrastructure cost.
When to Revisit the Decision
The infrastructure model decision is not a permanent choice — it should be revisited when key parameters change. The decision should be revisited when: volume crosses the 300K or 1M monthly message threshold; the programme adds in-house email infrastructure expertise that changes the self-build viability assessment; a new data residency or compliance requirement limits the ESP options available; the programme experiences sustained deliverability problems attributable to shared infrastructure constraints that the ESP cannot resolve; or the economics shift materially due to pricing changes at the current provider or new managed service options becoming available.
The annual infrastructure review — as part of the overall technology stack review — should include a comparison of current model cost and performance against the alternatives, updated for current volume, current expertise levels, and current performance. Programmes that perform this review annually and update the decision when parameters change consistently operate on the infrastructure model that best fits their current needs, rather than continuing with a model chosen for a previous phase of the programme that has since outgrown it.
The build-vs-buy-vs-managed decision is a strategic choice with compounding implications — the right model enables the operational discipline and deliverability performance that compounds into long-term programme advantage; the wrong model creates operational burden or performance constraints that compound into competitive disadvantage. Making it with complete information — visible costs, operational burden, performance gap, and expertise requirements — produces outcomes that visible-cost-only comparison consistently fails to achieve. That is the decision framework this note has attempted to provide: not to advocate for any particular model, but to ensure the comparison includes all the factors that determine which model produces the best outcome for a specific programme at its specific scale and capability level.
Email infrastructure, like most technology decisions, rewards clear thinking about total cost and total value over time rather than point-in-time line-item comparison. The programmes that make consistently good infrastructure decisions — choosing the model that fits their current scale, updating as they grow, and accounting for the full economic picture including performance gap and operational burden — compound the deliverability advantage that infrastructure excellence provides into the long-term commercial outcomes that make email one of the highest-ROI marketing channels available.
Infrastructure Assessment
Cloud Server for Email provides managed dedicated infrastructure — PowerMTA and MailWizz on isolated dedicated IPs, all configuration and monitoring managed, with transparent reporting and clear division of responsibility for programme management. Request assessment →