# Amazon SES vs self-hosted mail Source: https://wraps.dev/versus/amazon-ses-vs-self-hosted Amazon SESSelf-hosted (Postal, Listmonk, or your own MTA) You have decided not to pay a per-message platform fee. The remaining question is whether you rent delivery from AWS or run the mail server yourself — and what the second option costs in hours rather than invoices. Nobody arrives at this comparison by accident. You have already looked at the hosted APIs, decided the per-message premium is not buying you anything you want, and are now choosing between the cheapest credible rental and owning the machine outright. The honest framing is that this is not a cost comparison at all. Both options are cheap in dollars. One of them is expensive in a currency that does not appear on any invoice, which is the attention of the person who will be paged when a mailbox provider stops accepting your mail. ## At a glance |   | Amazon SES | Self-hosted (Postal, Listmonk, or your own MTA) | | --- | --- | --- | | What it is | Raw sending infrastructure from AWS | Open-source mail server you run yourself | | Published pricing | $0.10 per 1,000 emails on à la carte. New accounts are defaulted to the Essentials plan at $0.16 per 1,000; Pro is $105/mo + $0.22 per 1,000 and Enterprise $500/mo + $0.23 per 1,000. Plans are per-account, per-Region. | The software is free. You pay for servers, IP addresses, and your own time. | | Best for | Teams already on AWS with an engineer willing to own the plumbing. | Teams with a real reason to run an MTA and the operational capacity to staff it. | | Watch out for | Production access is an application AWS can refuse, and new accounts start sandboxed to verified addresses. No dashboard, no templates, and nothing stores your events until you build it. | IP warming, blocklist remediation, feedback loops, and DMARC alignment become an on-call rotation rather than a one-time setup task. | Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything. ## Where they actually differ ### What the word free is doing in each pitch Amazon SES SES charges per message and nothing else, which at any volume below a few million is a rounding error next to one engineer-day a month. There is no server, no address to warm by hand, no package to patch. The bill is legible and it arrives from a vendor you are probably already paying, which also means it goes through a procurement process that already exists. Self-hosted (Postal, Listmonk, or your own MTA) The software genuinely is free. What is not free is a machine with a static address and clean history, a second one so that a reboot is not an outage, backups of the queue, TLS certificates that renew, and the person who reads the logs. Teams costing this out reliably count the first item and reliably omit the last one, which is the one that dominates. ### Getting an address that anyone will accept mail from Amazon SES AWS hands you shared addresses with existing history on day one, and a dedicated address if you want one, with a managed warm-up path. Your job is to keep your bounce and complaint rates low enough that the shared pool stays healthy, which is a policy problem rather than a networking one. Self-hosted (Postal, Listmonk, or your own MTA) Your address starts with no history, which for a mailbox provider is indistinguishable from suspicious. You need forward and reverse DNS agreeing, a TLS certificate matching the hostname, DKIM signing, an SPF record and DMARC alignment before the first message, and then weeks of deliberately slow ramping. Most cloud providers also block outbound port twenty-five by default and unblocking it is a support request that can be refused. ### The approval nobody warns you about Amazon SES SES puts new accounts in a sandbox and asks you to apply for production access. It is an application AWS can refuse, and it is the part of an SES rollout most likely to slip a date. The compensation is that once it is granted the gate is behind you permanently and the account is yours across every region you enable. Self-hosted (Postal, Listmonk, or your own MTA) There is no single approval and there are many small ones. Your hosting provider has to allow outbound mail. Microsoft runs its own sender support process and Google its postmaster tooling, and enrolment in feedback loops is per-provider paperwork. Each one is minor and there is no end to them, because a new blocklist listing is a new form to fill in on somebody else's schedule. ### What happens at three in the morning Amazon SES Very little that is yours. A rate limit rejects a call and your retry logic handles it; a bounce arrives as an event and your consumer records it. The genuine SES incidents are regional and AWS is already working on them, which is a meaningfully different night from the alternative. Self-hosted (Postal, Listmonk, or your own MTA) The queue backs up because one large provider has started deferring you, and now the decision is whether that is a reputation problem, a content problem, a DNS problem or a full disk. Diagnosing a deferral means reading SMTP transcripts. Remediation means a delisting request and then waiting. That is a specific skill, it is rarer than it used to be, and the person who has it on your team is one person. ### Bounce handling and feedback loops Amazon SES SES processes bounces and complaints for you, maintains an account-level suppression list, and publishes both as events you can consume. Complaint feedback loops with the major providers are already wired in, so an abuse report becomes a structured event rather than a message in a mailbox nobody reads. Self-hosted (Postal, Listmonk, or your own MTA) You parse bounce messages yourself, which means implementing enough of the delivery status notification format to distinguish a permanently dead address from a temporarily full one, and suppressing correctly on the basis of that distinction. Feedback loops are individual enrolments per provider. Getting this wrong is invisible for a month and then it is your deliverability problem. ### Compliance, audit and the questionnaire Amazon SES Sending inherits the AWS control environment, so the security questionnaire that arrives with your first enterprise customer has an answer you can point at. Encryption in transit, key management, access control and logging are all existing AWS answers rather than things you have to write up about a box you administer. Self-hosted (Postal, Listmonk, or your own MTA) Every one of those questions is about a server you own. That can be exactly what you want — a regulator may require it, or an air-gapped environment may make the question moot — but it means the evidence is yours to produce, the patching cadence is yours to defend, and the incident response plan is a document somebody on your team has to write and test. ### Where the arithmetic actually crosses over Amazon SES Rental wins for almost everyone, because the per-message rate has to be multiplied by a very large number before it rivals a fractional engineer. Below roughly a million messages a month the discussion is not close, and the honest reason to leave is a requirement about control rather than a number on a spreadsheet. Self-hosted (Postal, Listmonk, or your own MTA) Ownership wins when volume is enormous and steady, when you already staff people who run mail infrastructure for other reasons, or when a rule about where messages may physically transit makes a hosted service impossible. Those are real situations. They are also much rarer than the number of teams who decide to self-host after reading a pricing page. ### Getting out again Amazon SES Your application talks to an API and your domains are verified against an account you control. Changing your mind means changing a client library and re-pointing DNS. Nothing in the decision is irreversible and nothing has to be scheduled around. Self-hosted (Postal, Listmonk, or your own MTA) Unwinding is mostly straightforward — you stop sending through your own host and start sending through something else — except for the part that is not, which is that any reputation you spent months building belonged to an address you are about to stop using. You start again from a cold identity, exactly as you did the first time. ## Pros and cons, side by side ### Amazon SES Strengths - Shared addresses with existing history accept your mail on day one, so there is no period during which the product works and the email does not. - Bounces and complaints arrive as structured events and an account-level suppression list already exists, which removes the need to implement any of the delivery status notification format. - Complaint feedback loops with the major providers are already wired in, so an abuse report becomes an event your code handles rather than a mailbox nobody reads. - The security questionnaire from your first enterprise customer has an existing answer about encryption, key management and access control that you did not have to write about a box you administer. Trade-offs - A new account sits in a sandbox until AWS grants production access, and that is an application a person reviews and can refuse on their own timetable. - Quotas and rate limits start conservative and rise by request, so a large first send is a ticket filed in advance rather than a thing you simply do. - The bill is small and it is a bill, which means a staging environment and a hobby project both generate an invoice line where the alternative generates none. - You are renting the delivery, so the pool health and the policy decisions behind it belong to somebody whose incentives are not identical to yours. ### Self-hosted (Postal, Listmonk, or your own MTA) Strengths - The software genuinely costs nothing, and for a team that already operates mail infrastructure the marginal cost of one more sending host really is small. - Messages never transit infrastructure somebody else operates, which is the one argument on this page that a regulator or a contract can actually require. - Nothing about the arrangement has a quota, a rate limit or an approval queue, so a large send is a capacity question rather than a permission question. - You see the entire SMTP conversation, which makes a stubborn deliverability problem diagnosable in a way that a hosted abstraction never quite is. Trade-offs - The address starts with no history, which a mailbox provider treats as indistinguishable from suspicious, and most cloud hosts block outbound port twenty-five by default with no obligation to unblock it. - You parse bounce messages yourself, which means implementing enough of the notification format to tell a permanently dead address from a temporarily full one, and suppressing on that basis. - Feedback loop enrolment is separate paperwork with each provider, and the consequence of skipping it is invisible for a month and then is your problem. - Diagnosing a deferral means reading SMTP transcripts and filing delisting requests, which is a specific skill held by one person on your team who also has other work. ## Pick in thirty seconds ### Choose Amazon SES if - Sending email is a supporting function of your product rather than the product, and you would rather spend the engineering elsewhere. - You want bounce processing, suppression and complaint feedback to exist on day one without anyone implementing the delivery status notification format. - Your compliance answers can lean on a cloud provider's control environment rather than on a server you administer yourself. - Volume is anywhere below the millions per month, where the per-message rate has not yet caught up with the cost of a person. ### Choose Self-hosted (Postal, Listmonk, or your own MTA) if - You already run mail infrastructure for other reasons and the marginal cost of one more sending host is genuinely small. - A contractual or regulatory rule requires that messages never transit infrastructure you do not operate. - Volume is large, steady and predictable enough that the per-message rate has become a line item somebody argues about. - You have a person — not a plan to hire one — who can read an SMTP transcript and file a delisting request without it ruining their week. ## What actually moves when you switch In roughly the order you would do it. The expensive parts of an email migration are never the send call. 1. Decide which direction you are actually going, because the hard parts sit in different places. Moving onto AWS means one approval — the production access application — after which the operational burden mostly disappears. Moving off it means acquiring an address, a hostname, a port twenty-five exemption, feedback loop enrolments and a person who reads logs, none of which is a single gate and all of which have no end date. 2. Treat the address and its history as the asset that does not travel. Whichever way you go, the thing you built is reputation attached to an address you are about to stop using, and the new one arrives at every mailbox provider as an unknown. Every other item on this list is work; this one is time, and the only way to spend less of it is to ramp deliberately rather than to switch on an evening. 3. Solve reverse DNS before anything else if you are leaving. Forward and reverse records have to agree, the HELO name has to match, and only whoever owns the address block can set the pointer record — which means it is a support request to your host rather than a change you make. Providers that reject on a mismatch do so silently from your perspective, so this is a thing to confirm rather than assume. 4. Get the port twenty-five position in writing before committing. Most cloud providers block outbound mail by default, several decline to unblock it for a new account, and the ones that do often want to know what you intend to send. Discovering this after the machine is built and the software is configured is the single most common way a self-hosting plan stalls, and it is answerable with one support ticket up front. 5. Build or dismantle the bounce parser deliberately. On AWS a bounce arrives as a structured event with a type and a subtype and the suppression happens whether or not you act. On your own host it arrives as a delivery status notification you have to interpret well enough to distinguish a dead mailbox from a full one, and getting that distinction wrong quietly poisons your standing over weeks rather than failing loudly. 6. Enrol in the feedback loops one provider at a time, and note that they are tied to the address. Microsoft and the other large providers each run their own process, enrolment is per sending address rather than per company, and moving addresses means doing it again. Google's postmaster tooling is domain-scoped rather than a feedback loop, so it survives an address change and tells you a different set of things. 7. Write down what happens to the queue when a provider starts deferring you. On a managed service a deferral is retried by somebody else's infrastructure. On your own host it is disk, a retry schedule you chose and a point at which you give up and bounce. Those three numbers are a policy decision, and the time to make it is not the morning the queue is full. 8. Cost the compliance evidence on the side you are moving to. Every question about encryption, patching and access control is answered by a cloud provider's control environment on one side and by a document you write and test on the other. If a security questionnaire is already part of your sales process, that document is a deliverable with a deadline rather than a background task. ## Questions to ask before you sign Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number. 1. Who on this team has read an SMTP transcript to diagnose a deferral, and what happens to our mail during their holiday? 2. Has our hosting provider confirmed in writing that outbound port twenty-five will be open for this account? 3. Does our requirement say messages must not be stored by a third party, or must not transit one — and does anybody know the difference matters? 4. What is our volume, and at that volume how many engineer-days a month would the per-message rate have to buy before renting looks expensive? 5. Who files the delisting request the first time we appear on a blocklist, and how quickly can they do it? 6. If we move, how long are we prepared to ramp before sending our full volume — weeks, or until somebody loses patience? 7. When the first enterprise security questionnaire arrives, who writes the answers about patching and incident response? ## Common questions ### Can I run a mail server on a cheap cloud instance? Technically yes and practically often not, because most providers block outbound port twenty-five by default and several will decline to unblock it for a new account. Address ranges belonging to the large clouds also carry poor reputation with mailbox providers, having hosted a great deal of abuse over the years. Teams who do this successfully usually rent from a host that specialises in mail and sells addresses with clean history, which is a different and more expensive thing than the cheapest instance available. ### How long does it take to warm a brand new sending address? Weeks, not days, and the schedule is driven by engagement rather than by the calendar. The usual shape is a small volume to your most active recipients first, roughly doubling every few days while watching deferrals and complaint rates, and pausing the ramp the moment one provider starts throttling. Sending your full list on the first day is the single most reliable way to have a new address treated as a spam source for months. ### Does self-hosting help with data residency requirements? It can, and it is one of the few arguments that survives scrutiny, but be precise about what the requirement says. Mail in transit crosses networks you do not own regardless of where the sending host sits, so self-hosting controls where messages are stored and processed rather than where they travel. If the requirement is about storage and processing, running your own host answers it. If it is about transit, nothing answers it except not sending email. ### What about Postal, Listmonk or Mailu specifically? They solve different halves. Postal is a full outbound platform with a web interface, queues and webhooks, which is the closest open-source equivalent to a sending API. Listmonk is a newsletter and list manager that expects an SMTP relay underneath it rather than being one. Mailu and similar stacks are aimed at hosting mailboxes for people, which is a harder problem than sending and usually not the one you have. ### Is there a middle option between these two? Yes, and it is the one most teams actually end up on: run open-source software for the parts you want to own, such as list management or template rendering, and hand the final delivery to a relay that maintains addresses and feedback loops professionally. You keep your data and your tooling, and you decline the part of the job that is a pager rotation. It is less ideologically clean than either pole and it is where most of the value is. ### What is reverse DNS and why does it block so many people? It is the record that maps your sending address back to a hostname, and receiving servers check that it exists and that it agrees with the name your server announces itself as. It blocks people because only the owner of the address block can set it, which means your hosting provider does it and not you. On a managed service the question never arises. On your own host it is a support ticket that has to be resolved before the first message, and a mismatch produces rejections that look like a reputation problem rather than a configuration one. ### Do feedback loop enrolments survive changing servers? Mostly not, because most of them are tied to the sending address rather than to your company or your domain. Move the address and you enrol again with each provider that offers one, and in the interim complaints stop arriving as structured reports and start being invisible. The exception is the domain-scoped postmaster tooling, which follows the domain and keeps working. Plan the re-enrolment as part of any move rather than discovering the silence a month later. ### How many messages a month justifies running the server? Rather more than most people assume, because the comparison is a per-message rate against a fraction of a person rather than against a server. At the rates a managed service charges, you need a very large number before the monthly spend approaches even a quarter of an engineer's time, and the operational work does not scale down neatly below that. Below roughly a million messages a month the arithmetic is not close, and the honest reasons to own the machine are about control rather than about the number. ### What does the AWS production access application actually ask? How you obtained the addresses you intend to mail, what kind of mail you will send, how you handle bounces and complaints, and how someone unsubscribes. It is a human reading an answer, deciding whether to lend you a shared reputation. Concrete answers referencing a suppression mechanism you have already built go through quickly; vague ones earn a request for more detail and another wait. It is the only step in an AWS rollout whose timing is not yours, which is a good reason to start it first.