Why Dedicated Infrastructure Scales Differently Than Shared ESPs

• September 2020
• Engineering Memo · External Release

Every high-volume email programme starts somewhere accessible — a shared ESP where setup takes hours, sending is managed through a web interface, and the monthly cost is a predictable subscription. At some point, this model stops being the optimal choice. The transition point varies by programme, but the pattern is consistent: beyond certain volume thresholds, dedicated infrastructure outperforms shared ESPs on cost per message, inbox placement, throughput capacity, and operational control simultaneously.

This note documents the scaling curves of shared ESP and dedicated infrastructure across these dimensions, identifies the volume thresholds where the crossover typically occurs, and explains the specific operational advantages that dedicated infrastructure provides that shared ESPs structurally cannot.

How Shared ESPs Work and Why They Scale Poorly

A shared ESP sends email for thousands of customers from a common pool of sending infrastructure — shared IP addresses, shared MTA capacity, shared ISP relationships. This model provides legitimate advantages at low volume: zero infrastructure setup, managed deliverability, and per-message pricing that makes the cost predictable and proportional to usage. The ESP's deliverability team manages IP reputation, responds to ISP blocking events, and handles the technical relationships with ISP postmaster teams on behalf of all customers.

The scaling problem is structural: in a shared pool, your sending reputation is partially determined by the behaviour of other customers sharing your IPs. A co-tenant whose campaign generates elevated complaint rates affects the shared IP's reputation — which affects your delivery rates. An ESP's deliverability team manages the aggregate of all its customers, not the individual requirements of each customer's programme. The attention your specific programme receives from the ESP's deliverability resources is proportional to how much revenue you represent to the ESP, not to how much your deliverability is worth to your business.

As volume increases, the co-tenant contamination risk scales with the pool size required to serve you. Large-volume customers on shared ESPs often receive isolated IP pools within the shared infrastructure — effectively approaching dedicated infrastructure — but at shared-infrastructure pricing that exceeds what dedicated infrastructure would cost at equivalent volume. The operational control remains limited because the customer still cannot directly configure MTA-level settings, implement custom bounce classification rules, or access the raw accounting log data that dedicated infrastructure provides.

The Economics of Scale: Where Dedicated Infrastructure Wins

Dedicated infrastructure has a fundamentally different cost structure from shared ESPs. Shared ESPs charge per message — the cost scales linearly with volume. Dedicated infrastructure has largely fixed costs — server hosting, IP allocation, MTA licensing — with volume having minimal marginal cost impact above certain thresholds. A dedicated PowerMTA server that can process 2 million messages per day costs approximately the same to operate at 500,000 messages per day as at 2 million per day; the fixed costs are spread over more messages as volume increases, driving the per-message cost downward continuously as volume grows.

The crossover point — where dedicated infrastructure becomes less expensive per message than a shared ESP — depends on the specific ESP's pricing and the specific dedicated infrastructure configuration. For most commercial ESP pricing models (€0.80–€1.50 per 1,000 messages) and typical managed dedicated infrastructure pricing (€490–€990 per month all-inclusive), the crossover occurs at approximately 300,000–600,000 messages per month. Below this volume, the shared ESP's per-message economics are better despite the higher rate, because the infrastructure fixed costs aren't spread over enough volume. Above this volume, the dedicated infrastructure's fixed cost structure produces progressive per-message cost advantages that widen with each additional volume increment.

At 3 million messages per month, a shared ESP at €1.00/1,000 costs €3,000/month. Managed dedicated infrastructure capable of this volume costs €990–€1,890 per month depending on configuration. The €1,100–€2,000 monthly savings at this scale pays for the dedicated infrastructure operator's time to manage the environment and still produces a cost advantage — while providing the operational control and isolation advantages that the shared ESP cannot offer at any price.

Performance Advantages That Don't Exist at Shared ESPs

Cost is one dimension of the dedicated vs shared comparison. Performance — specifically throughput, delivery window, and inbox placement — is where dedicated infrastructure's advantages are often more commercially significant than the cost difference.

Throughput control. On a shared ESP, your maximum throughput is determined by the platform's capacity management policies — which are designed for the average customer, not for your specific peak-volume requirements. During peak sending periods (Black Friday, end-of-month campaigns, event-triggered send spikes), shared ESP customers often experience delivery delays because the platform's shared capacity is under load from multiple customers sending simultaneously. Dedicated infrastructure's throughput is entirely allocated to your programme — during your peak, the full pool capacity is available with no shared-customer competition.

Per-ISP configuration. Shared ESP platforms configure ISP domain blocks for the aggregate of their customer base. Individual customers cannot add custom domain blocks for specific ISPs, adjust retry intervals for specific ISP greylisting patterns, or configure per-ISP connection limits based on their specific IP reputation levels. Dedicated PowerMTA provides per-ISP configuration at the granularity documented throughout this note series — configuration that can be tuned to each customer programme's specific ISP composition and reputation levels.

Isolation from co-tenant reputation events. When another shared ESP customer runs a campaign that generates elevated complaints — an event outside your control and outside your visibility — the shared IPs take a reputation hit that affects your delivery rates. On dedicated infrastructure, your IP pool's reputation is determined entirely by your programme's sending behaviour. Good programme management produces good reputation; no co-tenant event can contaminate it.

When to Stay on a Shared ESP

Dedicated infrastructure is not always the correct choice. For programmes below the cost crossover volume, the economics favour the shared ESP. For programmes without in-house technical resources to manage dedicated infrastructure (or without budget for managed infrastructure services), the operational simplicity of a shared ESP justifies the per-message premium. For new programmes that have not yet established their list quality, sending patterns, and content strategy, starting on a shared ESP allows iteration without infrastructure investment in a programme that may change significantly in its first 12 months.

The decision criteria for staying on a shared ESP: volume below 300,000 messages per month, no significant deliverability problems attributable to co-tenant contamination, operational team lacks email infrastructure expertise, programme is in early growth phase where infrastructure investment would precede programme stability. Any one of these conditions individually is not necessarily decisive — but if all four apply, the shared ESP is likely the correct choice for the current phase.

The decision criteria for moving to dedicated infrastructure: volume above 500,000 messages per month, deliverability problems that cannot be diagnosed or remediated because of limited shared ESP visibility, cost-per-message at shared ESP pricing is materially higher than dedicated infrastructure cost at current volume, programme has stabilised enough that the 4–8 week migration and warmup timeline is acceptable, and technical resources exist (in-house or through a managed service) to operate dedicated infrastructure correctly.

The Migration Timeline: Realistic Expectations

Migrating from a shared ESP to dedicated infrastructure requires more lead time than most operators initially estimate. The migration is not a cutover — it is a gradual transition over 4–8 weeks that allows IP warming to complete before full volume is moved to the new infrastructure. During this transition period, the programme operates on two infrastructures simultaneously: the existing shared ESP continues handling the majority of volume while the dedicated infrastructure warms and proves itself with a small, high-quality segment of the list.

The warmup protocol during migration: begin by routing 5–10% of volume through the new dedicated infrastructure using the highest-engagement list segment. Over 6 weeks, increase to 25%, 50%, 75%, and finally 100% as each week's accounting log data confirms delivery rates are at or above the existing ESP's performance. If the new infrastructure's delivery rates underperform at any volume level, hold at that level until the problem is diagnosed and resolved before increasing volume further.

The risk during migration: sending from both infrastructures simultaneously means recipients may receive campaigns from both sending environments. If the shared ESP and dedicated infrastructure use the same From: domain (which they will), DMARC aggregate reports will show both source IP ranges sending from the domain — the shared ESP's IP range and the dedicated infrastructure's range. Verifying that both sources pass DMARC alignment is part of the migration preparation, not something to discover during the live migration.

Programmes that complete this migration correctly arrive at dedicated infrastructure with the reputation foundation intact — the domain reputation built during shared ESP operation carries over to the dedicated infrastructure's sending, because domain reputation is domain-bound rather than IP-bound. The new IPs warm faster than they would for a brand-new domain, because the domain's established positive signals support the IP's warmup. This domain reputation continuity is one of the most important factors in a successful migration, and it depends on maintaining sending quality during the transition period rather than front-loading the dedicated infrastructure with low-engagement list segments during warmup.

Reputation Visibility: The Operational Control That Matters Most

The most under-appreciated advantage of dedicated infrastructure over shared ESPs is not cost or throughput — it is visibility. On shared infrastructure, the operator sees aggregate metrics: delivery rate, bounce rate, unsubscribe rate. On dedicated infrastructure, the operator sees the raw accounting log, which provides per-message, per-ISP, per-response-code delivery data with the granularity needed to diagnose specific problems.

A shared ESP that shows "95% delivery rate" is providing an aggregate. Dedicated infrastructure's accounting log shows: 97% delivery rate to Gmail, 94% to Yahoo, 98% to Microsoft, 89% to GMX — revealing that GMX is experiencing an above-average deferral rate that requires investigation, while the aggregate looks acceptable. The GMX-specific problem would not trigger an alert on the shared ESP reporting, but it would be actionable in the raw accounting log data.

Similarly, reputation signals on dedicated infrastructure are directly accessible. Gmail Postmaster Tools can be connected for the specific sending domain and specific sending IPs — all of which are under the operator's control and registered with Postmaster Tools. SNDS can be registered for the dedicated sending IPs directly. FBL data is received and processed by the operator's own pipeline. On shared infrastructure, these signals are mediated through the ESP's reporting layer — the operator sees what the ESP chooses to surface, not the raw data that the raw signals contain.

This visibility advantage compounds over time. Operators who can see their own raw data become more competent at diagnosing and addressing deliverability problems. They build pattern recognition from their own programme's data that makes them faster at identifying the root cause of delivery problems and more confident in the corrective actions they take. Operators on shared infrastructure who depend on the ESP's support team for deliverability diagnosis are limited to the ESP's bandwidth and attention — which is shared across all customers experiencing problems simultaneously. The dedicated infrastructure operator's diagnostic capability is limited only by their own technical skill and the time they invest in the data.

Multi-Brand Sending: Where Dedicated Infrastructure Is Structurally Required

Some programmes require dedicated infrastructure not primarily for volume or cost reasons, but for structural isolation requirements. A business that sends email for multiple distinct brands — with different audiences, different content, different complaint rate tolerances, and different sender reputations — needs infrastructure that can isolate each brand's reputation from the others. On shared ESP infrastructure, multi-brand isolation is limited: the brands may use different sending domains, but they share the ESP's IP pool.

Dedicated infrastructure enables complete pool isolation between brands: brand A's promotional campaigns route through pool A's dedicated IPs; brand B routes through pool B's dedicated IPs. Brand B's campaign that generates elevated complaint rates affects pool B's IP reputation without touching pool A. Brand A's high-engagement signals build pool A's IP reputation independently. The brands' reputations are genuinely isolated at the IP level, not just at the domain level.

This isolation is particularly valuable for businesses where one brand operates at a higher quality tier than another — where brand A has mature list management and excellent complaint rates, and brand B is still developing its programme with higher complaint and bounce rates. Without IP-level isolation, brand B's weaker sending practices affect the shared IPs that brand A uses, contaminating brand A's reputation through co-sending. With dedicated pool isolation, brand A continues building excellent reputation independently while brand B's separate pool absorbs its own reputation signals.

Agencies managing email for multiple independent clients have a similar structural requirement: client A's sending must be completely isolated from client B's sending at the IP level, not just at the domain level. A client incident — a poor campaign, a complaint spike, an emergency blacklisting — must not affect any other client. Dedicated per-client IP pools, managed within a common PowerMTA infrastructure, provide this isolation at a cost structure that supports the agency's business model in ways that maintaining separate shared ESP accounts for each client typically does not.

The Transition Point: A Decision Framework

The decision to move from shared ESP to dedicated infrastructure is best framed not as a binary threshold but as a multi-factor assessment. The factors, ranked by typical weight in the decision:

Monthly message volume is the primary driver. Below 300K messages per month: shared ESP economics are better. 300K–600K: evaluate based on other factors. Above 600K: dedicated infrastructure cost-per-message economics typically favour dedicated.

Deliverability problems attributable to co-tenant contamination can justify dedicated infrastructure even at lower volumes. If specific campaigns consistently underperform following periods of elevated shared pool complaint rates — observable through Postmaster Tools domain reputation spikes that correlate with days the shared ESP receives high-complaint campaigns from other customers — the isolation value of dedicated infrastructure may justify the investment below the pure cost crossover volume.

Programme stability and operational readiness determines whether the migration timing is appropriate. A programme that is actively iterating on its content strategy, acquisition approach, or campaign calendar is not in stable condition for a dedicated infrastructure migration — the warmup period requires consistent, high-quality sending from a stable programme, not a programme in flux. Stabilise the programme first; migrate second.

Technical resources for infrastructure management determine whether self-operated or managed dedicated infrastructure is appropriate. The technical requirements for operating PowerMTA correctly — SMTP protocol knowledge, Linux administration, DKIM and authentication configuration, accounting log processing — are non-trivial. Programmes without this expertise internally should evaluate managed infrastructure services rather than self-operated dedicated infrastructure. The operational advantages of dedicated infrastructure are only available if the infrastructure is correctly configured and actively managed; poorly configured dedicated infrastructure performs worse than a well-managed shared ESP.

Cost Modelling: Making the Comparison Concrete

Abstract cost comparisons are less useful than programme-specific calculations. The model requires two inputs: the current shared ESP monthly cost (total, not per-message, to account for any included features), and the estimated dedicated infrastructure monthly cost including managed service if applicable.

For a programme sending 2 million messages per month: shared ESP at €1.00/1,000 = €2,000/month. Managed dedicated infrastructure (PowerMTA + MailWizz, managed service, 4–6 IPs) = €990–€1,490/month. Monthly saving: €510–€1,010. Annual saving: €6,120–€12,120. These savings are in addition to the performance advantages — isolation, throughput control, visibility — that have indirect commercial value through better inbox placement and delivery window performance.

Add the warmup period cost: during the 4–8 week migration, both ESP and dedicated infrastructure costs overlap. At €2,000/month ESP + €990/month dedicated, the overlap period costs approximately €750–€1,500 in dual-platform operating cost. This one-time overlap cost is recovered in the first 1–2 months of dedicated-only operation at the rates above. The payback period for the migration investment is typically under 60 days for programmes at 2 million messages per month.

The cost model should also account for the deliverability improvement value. If the migration to dedicated infrastructure improves inbox placement by 5 percentage points — a conservative estimate for programmes where co-tenant contamination on the shared pool has been suppressing performance — the revenue value of the placement improvement (as calculated in the delivery rate vs inbox placement note) typically exceeds the infrastructure cost saving. The full return on migration includes both the direct cost saving and the indirect revenue gain from improved inbox placement, making dedicated infrastructure economically compelling well before it becomes cheaper on a pure per-message basis.

The scaling difference between shared ESPs and dedicated infrastructure is not a matter of dedicated infrastructure being objectively superior — it is a matter of the crossover points across cost, performance, and operational control dimensions all tending to occur in the same volume range (300K–600K monthly messages). Above this range, dedicated infrastructure's fixed cost structure, isolation properties, and operational visibility advantages make it the correct architectural choice for most programmes with stable sending patterns and available technical resources. The transition requires planning — migration timeline, warmup protocol, dual-platform overlap — but produces advantages that compound over time as the dedicated infrastructure's reputation and operational data accumulate into an increasingly valuable programme asset.

The programmes that successfully navigate this transition share a common characteristic: they approach it as a strategic investment rather than a cost optimisation. They move to dedicated infrastructure not primarily to save money, but to gain the operational control, isolation, and visibility that allows them to manage their email programme at the level of precision that their commercial dependence on email justifies. The cost advantage at scale is a welcome consequence, not the primary motivation. This perspective produces the deliberate migration planning — stable sending patterns, technical resources in place, warmup protocol designed, monitoring configured — that makes the transition smooth rather than disruptive.

Shared ESPs remain the correct starting point for most email programmes. Dedicated infrastructure is the correct destination for programmes that have grown beyond the shared model. The path between the two is well-defined; the decision of when to walk it is the strategic judgement that determines how much of the email programme's commercial potential is captured at each stage of its growth.