SMTP Relay vs MTA Ownership: The Operational Difference

• July 2022
• Engineering Memo · External Release

The majority of email programmes that send at moderate volume use third-party SMTP relay services (Sendgrid, Mailgun, Amazon SES, Postmark) rather than owning and operating their own MTA infrastructure. The relay model is attractive: no server management, no MTA configuration, no IP pool management. The relay handles the infrastructure; the programme focuses on the sending strategy and content.

As programmes grow in volume and deliverability sophistication requirements, the relay model's limitations become operationally significant. This note documents the specific differences between third-party SMTP relay and owned MTA infrastructure, the capabilities that become available when a programme moves to owned MTA, and the operational context in which each model is the more appropriate choice.

What Third-Party SMTP Relay Provides

A third-party SMTP relay accepts messages from the programme's application via SMTP or API, queues them, and delivers them through the relay's IP pool and infrastructure. The programme does not manage the sending IPs, the MTA configuration, or the retry logic — all of these are handled by the relay service. The programme's operational responsibilities are limited to authentication setup (DKIM, SPF for the relay's IP range), API integration, and campaign content.

The relay model's advantages at low volume: fast time-to-production (minutes rather than weeks), no infrastructure management overhead, shared IP pools that are pre-warmed by the relay service (though shared across all the relay's customers), and simple pricing based on message volume without fixed infrastructure costs. For programmes sending under 500,000 messages per month with modest deliverability requirements, these advantages often outweigh the limitations.

The relay model's operational limitations: shared IP reputation with other customers of the same relay (a high-complaint customer on the same shared IP pool affects all senders on that pool); limited per-ISP configuration (the relay's domain block settings apply to all customers and may not be optimised for any specific customer's sending profile); limited accounting log access (relay APIs provide summary delivery data, not the per-event structured accounting log that enables the monitoring practices in these notes); and DKIM signing from the relay's domain unless the programme configures custom domain signing (which may not be available on all plans).

What MTA Ownership Adds

Dedicated IP reputation. The programme's IP pool is used exclusively by the programme — no other senders share the reputation history. The IP reputation that the programme builds through its own sending practices is entirely attributable to its own signal quality. A high-quality list with low complaint rates builds strong IP reputation that translates directly into better inbox placement; this signal cannot be contaminated by co-tenant senders sharing the same IPs.

Per-ISP configuration control. Owned MTA allows precise PowerMTA domain block configuration for each major ISP: max-smtp-out, max-msg-per-connection, retry-after sequences, and max-msg-rate can be set based on the programme's specific reputation level and delivery patterns rather than the relay service's global settings optimised for its average customer. This per-ISP calibration produces more efficient delivery and less throttle pressure than any one-size-fits-most configuration a relay service applies to all customers.

Full accounting log access. Every delivery event — 250, 4xx, 5xx, with full SMTP response text — is recorded in the programme's own accounting log and can be processed into the operational database for the monitoring practices documented in these notes. This per-event data enables the per-ISP deferral rate analysis, per-campaign bounce rate calculation, and per-IP retry pressure monitoring that relay service APIs cannot provide.

Traffic type isolation. Owned MTA allows separate VMTAs for transactional, promotional, and cold email traffic — with dedicated IP pools and domain configurations for each. Relay services typically do not offer this level of traffic type isolation; all traffic shares the same IP pool unless the programme pays for dedicated IPs (which some relay services offer at premium pricing).

The Migration Decision: When to Move from Relay to Owned MTA

The decision to migrate from third-party SMTP relay to owned MTA is typically triggered by one or more of: volume growth that makes relay pricing less favourable than owned infrastructure costs; deliverability incidents that are attributable to shared IP reputation and cannot be resolved within the relay model; the need for per-ISP configuration control to address specific ISP relationship challenges; or the operational monitoring requirements that relay services cannot satisfy.

Volume threshold: for most relay services, owned MTA becomes cost-comparable at 2-5 million messages per month. Below this threshold, relay pricing is typically lower than the combined cost of MTA software licence, IP hosting, and infrastructure management. Above this threshold, relay pricing per message often exceeds the per-message cost of owned infrastructure, and the operational capabilities of owned MTA justify the switch on both cost and capability grounds.

Deliverability incident threshold: a single shared-IP incident that affects the programme's delivery performance — a co-tenant on the same relay IP pool generating a Spamhaus listing that affects all pool senders — makes the operational case for dedicated IPs. If the programme experiences two or more shared-IP incidents in 12 months, the migration to dedicated IPs (either through the relay's dedicated IP tier or through owned MTA) is likely cost-justified by the avoided incident cost.

The migration process from relay to owned MTA: provision and warm new dedicated IPs over 8 weeks while the relay continues handling production volume; configure the owned MTA (PowerMTA) with per-ISP domain blocks, DKIM signing, and accounting log pipeline; route a small percentage of production traffic through the new infrastructure for monitoring verification; gradually shift volume from relay to owned MTA over 4-6 weeks; fully decommission the relay relationship when the owned MTA is handling all production volume with confirmed delivery performance. This gradual migration avoids the delivery disruption that a sudden switch from relay to owned MTA would produce during the IP warmup period.

The choice between relay and owned MTA is not a permanent identity decision — it is an operational choice that should be revisited as the programme grows and its deliverability requirements evolve. Most programmes start on shared relay infrastructure and migrate to dedicated infrastructure as their scale and sophistication grow. Understanding the transition point — and executing the migration with sufficient lead time for IP warmup — is the strategic deliverability planning that avoids the delivery disruption that reactive migrations produce when programmes wait until shared-IP incidents force their hand.

The Hybrid Model: Relay for Burst, Owned MTA for Base Load

Some programmes use a hybrid model: an owned MTA for the regular sending programme (marketing campaigns, transactional email, cold email) and a third-party relay for burst sending that exceeds the owned IP pool's current capacity. This approach maintains the operational capabilities of owned MTA for the core programme while using the relay's pre-warmed shared IPs for volume spikes that would require extensive lead time to accommodate through IP pool expansion.

The hybrid model works best for programmes with predictable base volume but occasional peak requirements (seasonal retail, event-driven notification bursts). The base load through the owned MTA builds consistent IP reputation and accumulates the monitoring data that the operational practices in these notes require. The burst load through the relay uses shared IPs without reputation contaminating the owned pool — the relay-handled volume uses the relay's DKIM signing domain, not the programme's owned domain, unless the programme configures custom domain signing at the relay.

The risk of the hybrid model: if the relay burst uses the programme's sending domain (From: header with brand.com), the relay's DKIM signing configuration must correctly align with brand.com's DKIM keys, or the relay-sent messages will generate DMARC alignment failures that appear in the programme's DMARC aggregate reports. Ensuring correct authentication configuration for relay-sent messages is the same requirement as for any other third-party sending source — verify it with the pre-production authentication test before routing any production burst volume through the relay.

Dedicated IP Tiers at Relay Services: A Middle Ground

Most major relay services offer dedicated IP tiers that allow programmes to have exclusive use of specific IP addresses within the relay's infrastructure. This middle ground provides dedicated IP reputation (no co-tenant contamination) while maintaining the relay model's operational simplicity (no MTA software management, no server hosting). The dedicated IP tier at a relay service is typically priced at €20-50/month per dedicated IP, making it cost-comparable to hosting IPs independently once the relay service's per-message costs are accounted for.

The dedicated IP tier at relay services solves the shared IP reputation problem but does not solve the per-ISP configuration control problem or the accounting log depth problem. The relay service still applies its global domain block settings to all customers on dedicated IPs, and the delivery data available through the relay's API is still the summary delivery data rather than the per-event accounting log that monitoring practices require. For programmes whose primary concern is IP reputation isolation rather than per-ISP configuration control, the dedicated IP tier at a relay service may be a sufficient and cost-effective solution.

For programmes whose deliverability requirements include per-ISP configuration calibration, complete accounting log access, and traffic type isolation across multiple VMTAs, the relay service's dedicated IP tier is still insufficient — these capabilities require owned MTA infrastructure. The decision point: if the programme needs dedicated IPs and any of per-ISP configuration control, per-event accounting log, or multi-VMTA traffic isolation, owned MTA is the correct choice. If the programme needs dedicated IPs but is satisfied with the relay's standard per-ISP configuration and summary delivery data, the dedicated IP tier may be a practical intermediate step.

Operational Continuity During Migration

Migrating from relay to owned MTA while maintaining delivery performance requires careful attention to the reputation transition. The relay's IPs have accumulated reputation from the programme's sending history; the new owned IPs start with no reputation. This gap — from established relay reputation to zero owned reputation — cannot be bridged instantaneously. The 8-week warmup period for the new IPs is non-negotiable; the programme must plan for it.

The delivery performance during warmup will be lower than on the established relay IPs — the new IPs accept lower rates, have lower throughput capacity, and may experience more throttle. This is not a failure of the owned MTA approach; it is the expected behaviour during warmup. The programme's stakeholders should be briefed on the expected delivery performance during the warmup period so that they attribute any delivery slowdowns to the expected warmup behaviour rather than to the owned MTA infrastructure's capability.

The business case for accepting the warmup delivery performance reduction is the long-term operational control and deliverability capability that owned MTA provides. A programme that migrates from relay to owned MTA and completes the warmup correctly emerges from the migration with dedicated IP reputation, full accounting log access, per-ISP configuration control, and traffic type isolation — all of which produce better long-term delivery performance than the relay model could ever provide, regardless of how long the programme had used the relay.

The choice between SMTP relay and MTA ownership is ultimately a choice between operational simplicity and operational capability. The relay provides simplicity; the owned MTA provides capability. At low volume and low deliverability requirements, simplicity wins. At high volume or sophisticated deliverability requirements, capability wins. Making the choice correctly -- and making it before operational pressure forces a reactive migration -- is the strategic deliverability infrastructure decision that determines the programme's operational ceiling for years after the decision is made.

Total Cost of Ownership: Relay vs Owned MTA

A rigorous total cost of ownership comparison between relay and owned MTA includes all cost dimensions: infrastructure, software, management, and incident cost. The relay model's costs: per-message pricing (typically €5-15 per 1,000 messages for standard volumes, dropping on volume tiers), plus the cost of any dedicated IP add-ons. The owned MTA's costs: server hosting (€50-150/month for a capable sending server), IP hosting (€10-30/month per IP), MTA software licence (PowerMTA: €200-400/month depending on version), and infrastructure management (€490-990/month for managed service, or equivalent internal engineering time).

At 1 million messages per month: relay cost at €8/1,000 = €8,000/month. Owned MTA cost: €150 server + €120 IPs (4 IPs) + €300 MTA licence + €490 managed service = €1,060/month. The owned MTA is 7.5x less expensive at this volume — even before accounting for the capability premium (dedicated IPs, per-ISP config, full accounting log). At 500,000 messages per month: relay at €8/1,000 = €4,000/month vs owned MTA at €1,060/month — still 3.7x less expensive.

The volume breakeven — where relay and owned MTA costs are equivalent — varies by relay pricing tier, but for most programmes falls in the 200,000-500,000 messages per month range. Below this threshold, relay is cost-competitive. Above it, owned MTA is substantially less expensive at every volume level, while providing the operational capabilities that the relay model cannot match. This is why the migration to owned MTA is financially self-justifying at volume: the cost savings over 12 months typically fund the migration project cost and the initial managed service engagement several times over.

The incident cost dimension is harder to quantify but directionally clear: shared IP incidents at relay services have no occurrence cost at owned dedicated infrastructure. A single 48-hour delivery disruption from a co-tenant shared IP incident at a relay — affecting a programme that sends promotional campaigns generating €15,000 in daily revenue — costs more than 6 months of managed owned MTA service. At programmes with that commercial dependency on email delivery, the incident risk elimination alone justifies owned MTA regardless of the per-message cost comparison.

The operational decision between relay and owned MTA is both a cost decision and a capability decision. The cost analysis shows that owned MTA is more economical above the volume threshold. The capability analysis shows that owned MTA provides monitoring, control, and isolation capabilities that relay services cannot match. When both analyses point in the same direction — as they do for most programmes sending above 500,000 messages per month with commercial deliverability requirements — the migration decision is strategically clear. The only question is timing: proactive migration with IP warmup lead time, or reactive migration after a shared IP incident that forces the decision.

What to Expect from a Well-Managed Owned MTA

A programme that has migrated to owned MTA infrastructure and completed a successful IP warmup should observe the following operational characteristics compared to its relay-based sending history: lower per-ISP deferral rates (because the per-ISP domain block configuration is calibrated to the specific programme's reputation level rather than the relay's global settings); higher throughput per IP (because the IPs are exclusively used by the programme and have built reputation specifically from the programme's clean sending patterns); and higher accounting log data granularity that enables the monitoring practices documented throughout these notes.

The inbox placement improvement from dedicated IPs is typically visible within 4-8 weeks of warmup completion. Gmail Postmaster Tools domain reputation, which was previously attributed to the relay's signing domain, is now attributed to the programme's own DKIM signing domain — allowing the programme to see its own domain reputation for the first time and to track it as a deliverability management metric. This visibility is itself a major operational improvement: the programme can now act on reputation signals specific to its own sending rather than relying on the relay's aggregate data.

The management overhead of owned MTA — server maintenance, IP monitoring, PowerMTA configuration updates — is real but bounded. With a managed infrastructure service handling the day-to-day operational responsibility, the programme's internal team provides business context (campaign calendars, list quality updates, new traffic type requirements) while the managed service handles the technical infrastructure. This division of responsibility is the model that makes owned MTA operationally practical for programmes that do not have or want to build dedicated email infrastructure engineering capability internally.

The relay-to-owned-MTA migration is one of the most consequential infrastructure decisions an email programme makes. Done correctly, it produces a step-change improvement in operational capability, monitoring depth, and long-term deliverability performance. Done reactively under incident pressure, it creates the same disruption that any unplanned infrastructure change produces. Plan it proactively, execute it with sufficient IP warmup lead time, and the owned MTA will become the operational foundation that makes all subsequent deliverability management more effective and more clearly measurable than the relay model ever allowed.

The relay handles the infrastructure so you can focus on strategy. The owned MTA gives you the infrastructure control to execute the strategy at the highest level. Both are legitimate choices for the right programme at the right scale. Know which one you need, invest in it deliberately, and build on it confidently.

Making the Decision Well

The relay-vs-owned-MTA decision is made well when it is made with accurate information about the current programme state, the operational capabilities each model provides, and the realistic cost and capability comparison. The decision is made poorly when it is made reactively (after an incident forces the issue), without accounting for warmup lead time (assuming migration can be completed in days rather than weeks), or without understanding the capability gap between relay delivery data and owned MTA accounting log data (underestimating how much operational visibility improves with full per-event accounting logs).

Evaluate the decision annually as part of the infrastructure review. As volume grows, as deliverability requirements increase, and as the programme's commercial dependency on email becomes clearer, the balance between relay simplicity and owned MTA capability shifts. The point at which the capability advantages of owned MTA justify the migration investment will arrive for most commercial email programmes that are growing consistently. The programmes that make the migration proactively -- with 3-month lead time for warmup and managed service selection -- experience it as a planned capability upgrade. Those that make it reactively experience it as a crisis-driven migration with compressed timelines and compromised delivery performance during the transition. The difference is planning.

Plan the transition. Execute it with lead time. Build on the owned MTA with the confidence that comes from full operational control.

Operational control. Reputation ownership. Data depth. These are what owned MTA provides. Evaluate whether you need them; if you do, migrate deliberately.