Amazon SES vs. Self-Hosted MTAs for Multi-Customer Email Marketing

This review evaluates infrastructure choices for SaaS companies sending marketing emails on behalf of multiple customers, comparing Amazon SES with self-managed Mail Transfer Agents like KumoMTA or Postal.

TL;DR

Best for: Most SaaS companies requiring a scalable, cost-effective, and operationally lightweight solution for multi-customer email marketing should default to Amazon SES. Skip if: Your business model demands absolute control over the mail pipeline, requires highly specialized deliverability strategies not supported by SES, and you have significant in-house email operations expertise and budget for dedicated infrastructure. Bottom line: Amazon SES offers superior cost-efficiency and reduced operational burden for the vast majority of multi-customer email marketing use cases, abstracting away complex deliverability challenges.

METHODOLOGY

This v0 review draws on the founder ImNotACS's published claims and detailed questions within the Reddit thread, supplemented by general industry knowledge regarding Amazon SES and open-source Mail Transfer Agents (MTAs). We evaluate the two proposed architectures—listmonk + Amazon SES versus listmonk + self-managed MTA—based on the operational trade-offs, scalability, and cost implications outlined by the founder. This review covers the founder's stated goals for multi-customer marketing campaigns, including proper authentication (SPF, DKIM, DMARC), bounce/complaint handling, suppression lists, and warm-up strategies. What is not covered are independent performance benchmarks, long-term workflow integration specifics beyond the initial setup, or edge-case deliverability scenarios. Independent benchmarks and real-world performance testing for KumoMTA, Postal, and BillionMail at scale are pending. Update cadence: re-tested when claims diverge from observed behavior or new data becomes available.

• Tool name + version + date observed: Amazon SES (current service offering), KumoMTA (general concept), Postal (general concept), BillionMail (general concept), listmonk (general concept), observed 2026-06-04.
• Source signal URL: https://www.reddit.com/r/selfhosted/comments/1tw2xei/selfhosted_email_marketing_stack_ses_vs_own_mta/
• What's covered in this review: Founder's own claims, public artifacts (general knowledge of SES and open-source MTAs), technical detail in the linked thread regarding operational challenges.
• What's NOT covered: Independent performance metrics, long-term workflow impact, specific edge-case deliverability issues, or detailed configuration guides for each MTA.

WHAT IT DOES

The founder ImNotACS, representing a small SaaS company, seeks to build an email marketing infrastructure for multiple customers, each sending campaigns from their own domains. The core stack involves an open-source campaign/list manager, likely listmonk, combined with a delivery layer. Two primary approaches are under consideration: using Amazon SES as an SMTP/API relay or deploying a self-managed Mail Transfer Agent (MTA) like KumoMTA, Postal, or BillionMail on a VPS or dedicated server.

Abstracting email delivery with SES

Amazon Simple Email Service (SES) functions as a cloud-based email sending service. It handles the underlying infrastructure for sending emails, including IP reputation management, rDNS setup, and port 25 access. Users connect to SES via SMTP or API, providing the email content and recipient details. SES then manages the actual delivery to recipient mail servers. For multi-customer setups, SES allows verification of multiple sending domains and subdomains, and it automatically handles bounces and complaints, providing feedback via SNS or webhooks. SES offers both shared IP pools and dedicated IP options, with varying warm-up requirements depending on the choice.

Controlling the mail pipeline with self-hosted MTAs

Self-hosted MTAs like KumoMTA, Postal, or BillionMail provide full control over the email sending pipeline. These are software applications installed on a server (VPS or dedicated) that directly communicate with recipient mail servers. This approach requires manual configuration of DNS records (SPF, DKIM, DMARC), IP address management (rDNS, reputation), and active monitoring of deliverability metrics. The operational burden includes server provisioning, software installation and maintenance, security patching, and proactive management of port 25 access, which many cloud providers block by default. The benefit is granular control over every aspect of email sending, from queue management to specific retry logic.

WHAT'S INTERESTING / WHAT'S NOT

The most interesting aspect of this comparison, highlighted by the founder's questions, is the stark contrast in operational burden and risk management between the two approaches. Amazon SES effectively abstracts away the most challenging and time-consuming aspects of email deliverability: managing IP reputation, securing port 25 access, and handling the nuances of rDNS. For a small SaaS company, this abstraction translates directly into reduced engineering overhead and faster time to market for a multi-customer email product. The cost-effectiveness of SES, often measured in cents per thousand emails, is also a significant draw, especially for variable sending volumes.

What is not particularly interesting, but rather a persistent challenge, are the fundamental problems of email deliverability that the founder's questions reiterate. Issues like port 25 blocking by providers, the necessity of IP warm-up, and the complexities of managing sender reputation are well-known pain points in the email ecosystem. The founder's detailed questions about warm-up plans, recovery playbooks, and specific provider recommendations underscore that these are not new problems, but rather critical operational considerations that any email sender must address. The core decision then becomes whether to offload these known challenges to a managed service like SES or to internalize them with a self-hosted MTA.

A key missing piece from the founder's initial pitch is a clear articulation of why self-hosting an MTA might be preferable beyond the general desire for open-source tools. While control is a common argument, specific use cases where SES's capabilities fall short—e.g., highly specialized routing, custom bounce processing logic, or extreme volume requirements that exceed SES's initial quotas without extensive justification—would strengthen the case for self-hosting. Without such specific requirements, the default choice leans heavily towards the managed service.

PRICING

Amazon SES (as of June 2026):

• Free Tier: 62,000 emails per month when sending from an application hosted in EC2, or 1,000 emails per month when sending from any application. Includes 1,000 incoming messages and 1,000 messages for DMARC reporting.
• Pay-as-you-go: $0.10 per 1,000 emails sent. Data transfer out is $0.12 per GB. Dedicated IP addresses are $24.95 per month per IP.

Self-hosted MTA (as of June 2026):

• Server Costs: Varies widely based on provider (e.g., DigitalOcean, Vultr, Hetzner, OVHcloud) and server specifications. Expect $5-$50/month for a basic VPS, scaling up to hundreds or thousands for dedicated servers with high-volume needs. Crucially, finding providers that reliably allow outbound port 25 without extensive review or account age requirements is a challenge, often pushing users towards more expensive or specialized providers.
• Operational Overhead: This is the most significant cost. It includes engineering time for setup, maintenance, monitoring, security, deliverability management (IP warm-up, reputation, bounce/complaint processing), and troubleshooting. This can easily amount to thousands of dollars per month in personnel costs, far outweighing raw server expenses.

VERDICT

For the founder ImNotACS's goal of building a multi-customer email marketing infrastructure, Amazon SES is the unequivocally superior choice for most SaaS companies. It directly addresses the core pain points identified: port 25 limits, IP reputation management, and the complexities of warm-up, all at a highly competitive per-email cost. While SES has initial production access limits and daily send quotas, these are typically increased rapidly with healthy sending metrics (low bounce/complaint rates). The multi-customer/domain setup is well-supported, allowing verification of customer domains. Warm-up needs to happen per domain/subdomain, even with SES shared IPs, as reputation is largely tied to the sender's domain, not just the IP. The operational burden of self-hosting an MTA, including finding a compliant provider, managing server infrastructure, and actively maintaining deliverability, is substantial and rarely justified for a small SaaS company unless there are highly specialized requirements not met by SES. We recommend SES for its scalability, reliability, and the significant reduction in operational complexity it provides.

WHAT WE'D TEST NEXT

Our next steps would focus on empirically validating the founder's specific concerns. We would establish a test environment to compare: 1) The actual ramp-up speed and quota increases for new SES accounts with healthy sending metrics, quantifying typical starting quotas and the velocity of increases. 2) The effectiveness of different warm-up strategies for customer-owned domains using SES, particularly how quickly new subdomains gain reputation and if shared IP pools affect this. 3) A reproducible recovery playbook for deliverability issues, testing the impact of slowing down, segmenting users, and content changes on major ISPs like Gmail and Outlook. 4) A head-to-head benchmark of a self-hosted KumoMTA instance against SES for latency and throughput under controlled conditions, specifically evaluating the operational overhead required to achieve comparable deliverability rates. This would include a detailed cost analysis of engineering time versus SES fees at various scales.

Pull quote: “Amazon SES offers superior cost-efficiency and reduced operational burden for the vast majority of multi-customer email marketing use cases, abstracting away complex deliverability challenges.”