# Amazon SES vs MailerSend Source: https://wraps.dev/versus/amazon-ses-vs-mailersend MailerSend's product is a template builder a non-engineer can open, wrapped around a competent email API. SES has no builder and never will. That single capability is most of what separates them. Strip away the marketing on both sides and this comparison reduces to one question: does somebody who cannot open a pull request need to change what an email says? If the answer is no, SES is cheaper, more flexible and already inside infrastructure you run. If the answer is yes, MailerSend has built its entire product around that person, and SES has built nothing for them and has no plans to. Everything else on this page is a consequence of that one difference. ## At a glance |   | Amazon SES | MailerSend | | --- | --- | --- | | What it is | Raw sending infrastructure from AWS | Email API with a drag-and-drop template builder | | 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. | Free 500/mo (100/day). Starter $35/mo at 50K ($31.50 annual). Professional $110/mo at 50K ($99 annual). Overage from $1.30 per 1,000, falling as plan size grows. | | Best for | Teams already on AWS with an engineer willing to own the plumbing. | Mid-market teams who need a template builder a non-engineer can open. | | 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. | The free tier is only 500 emails a month, and Professional costs $75/mo more than Starter for identical volume — you are buying seats and retention, not sending. | 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 ### The template builder, which is the whole argument Amazon SES SES has a template API with token substitution, and the prevailing practice is to ignore it and render HTML in your own application instead. That makes templates code — versioned, reviewable, portable, testable — and completely invisible to anyone without repository access. A preview environment for non-engineers is a thing you build, and most teams never do, so the person who wants to change a subject line files a ticket. MailerSend A drag-and-drop builder with variables, conditional blocks and a preview, aimed squarely at a marketer or a support lead. They change the copy, they see what it will look like, they publish, and no deploy happens. For a company with twenty transactional messages that need occasional wording changes, this removes a recurring low-value interruption from the engineering queue, which is worth considerably more than it sounds. ### The free tier, and what it is actually for Amazon SES There is no meaningful free tier any more. The old arrangement people remember is gone, new accounts land on a metered plan rather than the flat rate, and the plan is scoped per account and per region. SES is extremely cheap and it is not free, so a staging environment or a hobby project is a small bill rather than no bill. MailerSend A free allowance that is small in both dimensions — a low monthly cap and a low daily one. It is enough to evaluate the product and not enough to run anything real, including most staging environments. Treat it as a trial with no clock rather than as a tier you could live on, because teams that plan around it discover the daily cap on the first busy Tuesday. ### What the higher plan actually buys Amazon SES Nothing, in this sense. SES has no feature tiers: the plan you select changes the rate you pay, not the capabilities you get. Whatever is available on day one is available forever, which is either reassuring or bleak depending on what you were hoping for. There is no upgrade path because there is nothing above you. MailerSend The step from Starter to Professional costs substantially more for the same included volume, and what it buys is seats, longer retention and team features rather than sending. That is worth naming plainly because it is the most common place an evaluation goes wrong: somebody prices Starter, then discovers the requirement list needs Professional, and the comparison against SES changes shape entirely. Price the tier with the features. ### Multiple brands and multiple domains Amazon SES SES handles many verified identities in one account without difficulty, and configuration sets let each one carry its own event destinations and reputation options. What it does not provide is any notion of a workspace, a client or a permission boundary between them, so an agency running mail for twelve customers is building its own separation, its own access control and its own reporting split. MailerSend Domains, templates and users are organised in a way that suits running several brands, with the seat and permission model that Professional adds being precisely what an agency needs. For a company sending on behalf of clients, or a group with several product brands, this organisational shape is a real product feature rather than an administrative convenience. ### Inbound and the surrounding surface Amazon SES SES can receive mail in a subset of regions through receipt rule sets that store to S3, invoke a Lambda, publish to SNS or reject. It is powerful and entirely unparsed — you get raw MIME and write everything after that. Combined with the rest of AWS it is the most flexible option here by a distance, and flexibility is another word for work. MailerSend Inbound routing exists and is more finished than SES's in the sense that fields arrive parsed, and it is a smaller part of the product than it is for a vendor built around routing. For the common case of getting replies to a webhook it is adequate and quick. For anything structurally unusual it will be the wrong shape, and the escape hatch is another vendor rather than another line of code. ### Deliverability and who watches it Amazon SES Your reputation alone, in your own account, with your own metrics and nobody monitoring them on your behalf. Warming a new identity is real work, the isolation means a neighbour cannot hurt you, and the absence of anyone noticing your problem is the cost. Once the reputation is established it belongs to an account you keep, which is the durable advantage of this side. MailerSend MailerSend's shared pools with dedicated options on the higher plans, operated by a team whose job it is. For a mid-market company with no deliverability expertise this is a genuine service. The standard exposure applies: the standing you enjoy belongs to the vendor and does not travel with you, so leaving means starting a reputation from nothing. ### The shape of the bill Amazon SES Per message, no platform fee, no plan to outgrow, billed by AWS alongside everything else and cheap enough at any real volume that the comparison stops being close. The complications are AWS complications — per account, per region, and a metered plan for new accounts — rather than surprises. Cost is a straight line with a small slope. MailerSend A plan with an included volume and an overage rate that improves as the plan grows, with the Starter-to-Professional step being about seats and retention rather than sending. Predictable and considerably more expensive per message. The fair comparison is not the raw rate: it is MailerSend against SES plus whatever you would build to give a non-engineer a template they can edit. ### Control over the message itself Amazon SES Total. SES accepts raw MIME if you want it, so headers, encoding, multipart structure, attachments and list-unsubscribe behaviour are all yours to determine exactly. If you have a specific requirement about how an email is constructed, SES will honour it and most products in this category will not even expose the option. MailerSend Whatever the builder and the API model expose, which covers ordinary transactional email comfortably and stops there. This is the usual product-versus-primitive trade and it is invisible until the day you need something specific. The failure mode is not that it is difficult — it is that it is unavailable, and the workaround is to stop using the template system you chose the product for. ## Pros and cons, side by side ### Amazon SES Strengths - Many verified identities live in one account without friction, and configuration sets give each of them its own event destinations and reputation options. - The plan changes the rate rather than the capability, so there is no tier above you holding a feature hostage and no evaluation that goes wrong at the pricing page. - Raw MIME is accepted in full, which means a header, an encoding, a multipart arrangement or a list-unsubscribe behaviour is yours to set exactly. - Inbound receiving composes with the rest of AWS — store the raw message, invoke a function, publish to a topic, reject outright — with rules evaluated in an order you control. Trade-offs - The template API offers token substitution and effectively nothing else, so the person who wanted to change a subject line is filing a ticket either way. - There is no workspace, no client boundary and no seat model, so an agency running mail for a dozen customers builds its own separation, access control and reporting split. - Inbound arrives as raw MIME, and every parsed field another vendor would have handed you is a parser you write and then maintain against real-world mail. - Nothing stores your activity: events are published and then they are gone unless you built the destination, so the searchable history a support lead relied on has to be constructed first. ### MailerSend Strengths - A drag-and-drop builder with variables, conditional blocks and a preview, aimed at a marketer or a support lead rather than at whoever last touched the codebase. - Domains, templates and users are organised in a way that suits running several brands, which is an actual product feature for an agency rather than an administrative convenience. - Inbound arrives with fields already parsed, so getting replies to a webhook is a short afternoon instead of a parser with a long tail of encoding bugs. - It operates its own sending infrastructure rather than reselling somebody else's, which makes the deliverability difference between the two options real rather than an artefact of two accounts on one substrate. Trade-offs - The step up between plans buys seats, retention and team features at the same included volume, which is where most evaluations of this product produce the wrong number. - The free allowance is capped on both a monthly and a daily basis, so it evaluates the product and will not run a staging environment through a busy Tuesday. - You work inside the builder's model of an email, and the failure mode is not difficulty but unavailability — the workaround is abandoning the template system you bought the product for. - The standing behind your mail belongs to the vendor's pools, so leaving means starting a reputation from nothing regardless of how long you stayed. ## Pick in thirty seconds ### Choose Amazon SES if - All email content is generated by code and nobody outside engineering will ever need to change it. - Volume is high enough that per-message economics dominate, and you are already inside AWS with an engineer to own the plumbing. - You need exact control over message construction — headers, encoding, attachments — that a product-shaped tool does not expose. - Sending reputation should attach to an account you keep, so changing the tooling above it is never a migration. ### Choose MailerSend if - Someone without commit access needs to edit transactional email copy, and the current arrangement has them filing tickets to do it. - You run mail for several brands or clients and want domains, templates and permissions organised that way out of the box. - Nobody in-house wants to own deliverability monitoring, and a managed pool with dedicated options above it is the simpler answer. - Volume is modest enough that the plan price is smaller than the engineering cost of building a template experience SES will never provide. ## 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. Settle the org question first, because it decides the rest. If somebody without commit access edits transactional copy today, moving to SES converts that into a ticket queue unless you are also budgeting a preview and editing path. That is the migration. Everything below is mechanical by comparison, and teams that skip this step ship a technically clean move and then spend a year being asked when the editor is coming back. 2. Export the suppression lists individually and expect two of them to have nowhere to go. A product built for this market keeps hard bounces, spam complaints and unsubscribes apart, and often a manual blocklist that accepts whole domains as well as addresses. SES has two reasons and takes addresses only. The unsubscribes become your table, and any domain-level block becomes a condition in your own code that runs before the send call. 3. Convert every template-id send into a render. Messages here are triggered by referencing a stored template plus a personalization payload, and the conditional blocks inside that template execute on the vendor's side. Moving the body into your application makes the variable contract explicit for the first time, and the variables that were quietly optional are the ones that start rendering as empty blocks in production. 4. Rebuild the inbound path around raw MIME. Parsed fields arriving at a webhook and a raw message landing in object storage are not the same integration with a different address on it. Anything downstream that consumed a clean from, subject and text body now sits behind a parser you own, and the messages that break it are multipart replies from real mail clients rather than anything you would write as a fixture. 5. Stand up event publishing before you need to answer a question. Activity search and analytics are retained by plan on one side and do not exist at all on the other: SES emits delivery, bounce, complaint, open and click events to a destination you configure and stores nothing itself. If nobody wires that up on day one, the first support question about last month has no answer and no way to get one retroactively. 6. Redesign the multi-brand separation as IAM and configuration sets. Seats, roles and a per-client view have no AWS counterpart beyond policies you write, so an agency's clean boundary between customers becomes a permissions design exercise. It is entirely doable and it is a piece of infrastructure with an owner, which is a different thing from a checkbox on a plan. 7. Account for the genuinely different network. This is not a case of two products sitting on the same substrate, so your placement can move in either direction for reasons that have nothing to do with your list. Warm the new identity across a subdomain, start with your most engaged recipients, and hold both senders live long enough to compare rather than long enough to hope. 8. File the production access application with the suppression work already done. The sandbox gate asks how addresses were collected and what happens to a bounce, and the export above has just made those answerable in specifics. Vague answers earn a request for more detail, and that round trip is the part of an SES rollout most likely to move a launch date. ## 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. How many times last quarter did somebody outside engineering ask for a wording change to a transactional email? 2. Which plan row actually contains the seats, retention and features on our list, and is that the row we have been comparing? 3. Do we block any sending at the domain level today, and where would that rule live if the suppression list only accepted addresses? 4. Who would own the MIME parser once inbound stops arriving pre-parsed, and have they seen what real replies look like? 5. Where will delivery events be stored, and who is responsible for the fact that nothing stores them by default? 6. If we run mail for several brands or clients, what enforces the boundary between them and who audits it? 7. Are we comparing per-message rates, or comparing one of them against the other plus the template experience we would have to build? ## Common questions ### Why not just use the SES template API? Because it is minimal and nobody enjoys it. It offers token substitution and little else — no conditionals worth the name, no layouts, no preview, and no interface a non-engineer would open. Managing templates means API calls or CLI commands. Most teams conclude within a week that rendering in their own application is better, which is true, and which still leaves the person who wanted to change a subject line filing a ticket. ### Can I build a template editor on top of SES? Yes, and it is a bigger project than it looks. A usable version needs storage and versioning, a visual or markup editor, variable substitution with a preview against realistic data, rendering that survives the major email clients, an approval step and a permission model. Teams that start this generally ship something in a quarter that engineering is proud of and the intended users avoid. Buy it or use a platform layer; building it rarely pays. ### What is the real difference between MailerSend's Starter and Professional? Not sending volume — the included allowance is the same on both at the comparable size. Professional adds seats, longer data retention and team features, which is to say it is priced for organisational capacity rather than for throughput. That is legitimate and it is also why the plan comparison surprises people. Decide which features you need first and price the row that contains them, because the headline row probably does not. ### Is MailerSend built on Amazon SES? It operates its own sending infrastructure rather than reselling SES, so a move between the two genuinely changes the network, the pools and the relationships behind your mail. That matters because it makes deliverability differences between them real rather than an artefact of two accounts on the same substrate, which is the situation with several other providers in this market. ### How much would I save moving to SES? Per message, a great deal, and the honest comparison is not per message. Price SES plus the work to replace what you are using: a template experience for non-engineers, an event pipeline, somewhere to search sent mail, and someone to watch deliverability. At high volume SES still wins clearly. At moderate volume with a marketer editing templates weekly, the saving is frequently smaller than the interruption cost it creates. ### Where do domain-level blocks go on SES? Into your own code, because the suppression list takes addresses and nothing larger. Products in this market commonly let you blocklist an entire domain, which teams use for competitors, for a customer who asked to be excluded wholesale, or for a disposable-address service that keeps producing complaints. None of that has a representation in AWS. The replacement is a rule evaluated immediately before the send call, which means it has to be in the path of every send site rather than configured once in a console. ### How do I search sent mail once I am on SES? You build the place the search runs against. SES publishes delivery, bounce, complaint, open and click events to a destination you nominate and keeps nothing itself, so there is no activity view and no retroactive way to recover a window you did not capture. The usual shape is events onto a stream, into storage with a lifecycle policy, behind a small internal page. It is a day or two of work and it has to exist before the first question rather than after it. ### Can an agency keep clients separate on SES? Yes, and it is a design exercise rather than a setting. Separate AWS accounts under an organisation gives the cleanest boundary and the most administration; one account with per-identity IAM policies and a configuration set per client is lighter and relies on your policies being right. Either way the reporting split, the access control and the per-client view are things you own. Compare that honestly against a plan whose seat and permission model already does it. ### Does my template HTML transfer? The markup mostly does and the behaviour mostly does not. A builder emits ordinary table-based HTML that SES will happily send, so the visual layout survives a copy and paste. What does not survive is everything the builder was evaluating at send time: conditional blocks, repeated sections and variable defaults all execute on the vendor's side against the payload you supplied. Those become rendering logic in your application, and a conditional that silently resolved to nothing is the one that ships broken.