# Amazon SES vs Postmark Source: https://wraps.dev/versus/amazon-ses-vs-postmark Postmark is the most deliberately narrow product in transactional email and SES is the least opinionated infrastructure in it. Comparing them on price misses what each is actually selling. Postmark has spent over a decade refusing to become a platform. It sends transactional email, keeps the marketing mail off the same pipes on purpose, stores what it sent so you can read it back, and answers support tickets with people who know how mail works. SES has spent the same decade being infrastructure: enormous, cheap, indifferent, and entirely willing to let you make a mess. The choice is not between a good product and a bad one. It is between buying a mail operation and running one. ## At a glance |   | Amazon SES | Postmark | | --- | --- | --- | | What it is | Raw sending infrastructure from AWS | Transactional email API, deliverability-first | | 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. | Basic $15, Pro $16.50, Platform $18 per month — each including 10,000 emails. Overage runs $1.80, $1.30, and $1.20 per 1,000 respectively. Dedicated IP $50/mo on Pro and above, 300K/mo minimum. | | Best for | Teams already on AWS with an engineer willing to own the plumbing. | Transactional email where inbox placement matters more than unit price. | | 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 economics invert at volume — roughly $630 at 500K/mo against $50 of raw SES. Marketing tooling is deliberately thin, and the early-2026 repricing means long-standing accounts are not on these numbers. | 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 ### Separating transactional mail from everything else Amazon SES SES gives you configuration sets and verified identities, which are the raw materials for the same separation, and nothing that enforces it. A team that puts its password resets and its product newsletter behind one identity with one set of defaults has done something SES considers perfectly reasonable, right up until a campaign's complaint rate drags the account reputation down and the resets start landing in spam. The separation is available. Nothing reminds you to build it. Postmark Postmark makes it structural. Transactional and broadcast mail live in separate streams that do not share reputation, and the product will argue with you if you try to push bulk mail down the transactional one. That is an opinion enforced in software, and it removes the single most common self-inflicted deliverability injury in this category — which is the honest version of why its placement reputation is what it is. ### Reading back what you actually sent Amazon SES SES stores nothing. Deliveries, bounces, complaints, opens and clicks can be published to SNS, EventBridge or Firehose, but only if you configure it, and the message body is never retained anywhere by AWS. When support asks what did the email say, the answer comes from your own rendering code and your own archive, both of which you built. The archive ceiling for stored mail, where you enable it, is permanent rather than a rolling window — but again, only once you have built toward it. Postmark Postmark keeps the rendered message, not just the event, and the activity view will show you the headers, the HTML and the delivery trace for a specific recipient. This is the feature that quietly justifies the price for support-heavy products: a customer says they never got it, and somebody who is not an engineer resolves the question in under a minute without opening a log query. ### Who owns the reputation, and what that means when it goes wrong Amazon SES You do, alone. Your bounce rate, your complaint rate, your account standing, visible in your own console and nobody else's problem. The upside is isolation: a neighbour's bad month cannot touch you. The downside arrives the first time something does go wrong, because there is no one whose job it is to notice. Diagnosing a placement problem on SES means reading your own DMARC reports, your own engagement data and a postmaster tool, and the tooling to do that is not supplied. Postmark Postmark's, managed by people who do it professionally and shared across its transactional pool. Their incentive to keep it clean is direct and their willingness to remove customers who damage it is well established. What you are buying is not a secret technique — it is diligence performed continuously by somebody else, plus a support channel staffed by people who can read a bounce trace. ### The support conversation Amazon SES AWS support is a separate purchase, and on the free tier it is documentation and forums. For a mail problem specifically this is worse than it sounds, because the failure modes are subtle — an alignment mismatch, a Gmail policy change, a reputation dip with no obvious cause — and the first-line response to a paid ticket will not be from a deliverability specialist. Most SES teams end up self-sufficient by necessity rather than choice. Postmark Support is the product as much as the API is. Tickets go to people who have operated mail infrastructure, the answers address the actual question, and a placement problem gets a real investigation rather than a link to a runbook. Teams describe this as the reason they stay after the invoice stops being the cheapest option, which is an unusual thing to be true of a support department. ### Where the economics invert, and how sharply Amazon SES Metered per message with no platform fee, and cheap enough at any meaningful volume that the comparison stops being close. The subtleties are that new accounts land on a metered plan rather than the old flat rate, and that the plan is scoped per account and per region. Nothing about the shape changes as you grow, which is the entire argument for it: the bill is a straight line with a small slope. Postmark A plan with an included allowance and an overage rate that falls as the plan rises. At ten thousand messages a month the difference against SES is small enough that it should not decide anything. At half a million a month the same comparison is a substantial recurring number, and the early-2026 repricing means an account opened years ago is not on the figures a new one is quoted. Check what you are actually on before modelling anything. ### Templates and who is allowed to touch them Amazon SES SES has a template API with token substitution and nobody likes it. The prevailing pattern is to render HTML inside the application and hand SES a finished string, which makes templates part of the codebase — reviewable, versioned and portable, and also invisible to anyone who cannot open a pull request. A preview environment for non-engineers is another thing you build. Postmark Postmark ships a template editor with layouts, a set of well-tested starting points, and a preview that renders against real clients. It is deliberately not a marketing designer and it is not trying to be one. For a product with twenty transactional messages that occasionally need a copy change, it is close to exactly the right size, and the copy change does not need a deploy. ### What leaving costs in each direction Amazon SES Leaving SES is mostly a code change, because the verified domains and the reputation are attached to an account you keep. You can run a second provider from a separate subdomain and move traffic class by class with no drama. That reversibility is a real asset and it is worth more than it looks on the day you sign up. Postmark Leaving Postmark means re-verifying elsewhere and starting reputation from nothing, because the pool you were delivering from was never yours. The API surface is small so the code is a day, but the stored history does not travel and the placement you enjoyed was a property of their operation rather than of your domain. Plan the move as a ramp, not a cutover. ## Pros and cons, side by side ### Amazon SES Strengths - Metered with no included allowance to price around, which past the low hundreds of thousands a month stops being a close comparison and becomes the reason large senders are here at all. - Identities, configuration sets and dedicated addresses are raw materials rather than an opinion, so a traffic split nobody else anticipated — per brand, per tenant, per regulatory boundary — is something you can actually construct. - Where you configure archiving, the ceiling is permanent rather than a rolling window, which is the difference between a retention policy a regulator accepts and a debugging convenience. - Leaving is about as cheap as it gets in this field: the verified domains and the standing behind them live in an account you keep, so a second provider runs from a sibling subdomain and takes traffic at whatever pace you choose. Trade-offs - Nothing stops you putting a campaign and a password reset behind the same identity, so the most common self-inflicted placement injury in the category is the default behaviour and no part of the console will mention it. - The rendered message is never kept, so what did we actually send them is answerable only from an archive you built in advance — and it is not a question you can answer retroactively. - Diagnosing a placement problem means reading DMARC aggregate reports, engagement data and postmaster tooling, none of which AWS supplies and all of which somebody on the team has to learn on a bad week. - First-line support is not staffed by deliverability specialists, and no support plan reliably converts a mail question into a conversation with somebody who has operated mail. ### Postmark Strengths - The split between bulk and transactional traffic is enforced by the software rather than left to a convention the team will abandon in eighteen months, which removes the failure that puts receipts in the spam folder the week after a campaign. - The activity view holds the rendered body and the delivery trace for a named recipient, so a support agent closes the did-it-arrive ticket in under a minute without escalating to engineering or opening a query console. - Tickets are answered by people who have run mail infrastructure, and a placement question produces an investigation instead of a runbook link — which is most of what the per-message premium is actually buying. - Templates have layouts, versioning inside the product and a preview rendered against real clients, so changing the wording of a receipt is not a deploy. Trade-offs - The standing you deliver on belongs to their pool, so leaving means verifying elsewhere and earning reputation from zero while the stored history stays behind on their side of the line. - The plan ladder crosses a metered rate somewhere in the low hundreds of thousands a month, and the early-2026 repricing means a long-standing account is not on the figures a new one is quoted — confirm which you are on before modelling anything. - No segmentation engine, no visual campaign designer, no automation, and a decade of the company declining to build them, which makes lifecycle marketing a second product and a second consent record by design. - Retention is a window rather than a policy. The tooling inside it is unusually good and there is nothing whatsoever outside it. ## Pick in thirty seconds ### Choose Amazon SES if - Volume is high enough that the difference is a headcount rather than a rounding error, and somebody on the team genuinely wants to own mail operations. - Message content and delivery events have to live in storage you control, on a retention policy you set, because of an audit or a regulator rather than a debugging habit. - You are already inside AWS and want mail under the same account, the same IAM model and the same invoice as everything else. - You need throughput that rises on request rather than a fixed included allowance, because the traffic is batch-shaped. ### Choose Postmark if - Inbox placement for password resets and receipts is a business risk rather than an engineering preference, and you would rather rent diligence than perform it. - Support agents need to answer did this customer get the email without escalating to an engineer, using the rendered message rather than a log line. - You want the transactional and broadcast separation enforced by the product, because in practice nobody on the team will enforce it by convention. - Volume is in the tens of thousands a month, where the price difference does not fund the operational work that SES requires. ## 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. Open the SES production-access application first, and answer it the way you would answer an onboarding questionnaire rather than a form: how addresses are collected, how bounces and complaints are processed, what the mail is for. The decision is on AWS's calendar, and this is the step most likely to move the date. 2. Map the message streams onto separate verified subdomains, not just onto configuration sets. The streams were performing reputational isolation; configuration sets only separate event routing. Reproducing what you had means distinct sending identities, and above a certain volume distinct dedicated addresses behind them. 3. Export the suppression list from every stream rather than from the transactional one. Postmark keeps suppressions per stream, so a single export is a partial export, and the broadcast stream is precisely where the complaints you least want to repeat were recorded. 4. Pull the activity history you still care about while the account is open. Postmark holds the rendered message and AWS will hold nothing, so anything not exported is the last copy of what you sent. Teams generally discover this during the dispute that needed it rather than during the move. 5. Re-implement the templates rather than translating them. Layouts and the substitution syntax are evaluated inside Postmark, and the SES template API is not somewhere you want them to land. Rendering in the application and sending finished HTML is where these migrations end up anyway, so go straight there. 6. Rebuild the support workflow before the cutover, because the activity search an agent was using is the feature the invoice was paying for. On the other side that is a pipeline — configuration set, event destination, somewhere to store it, an index, and an interface a non-engineer can use — and a half-finished version is worse than being honest about not having one. 7. Rewrite the event consumers. Postmark posts one JSON object per event to a URL nominated per stream; SES publishes through SNS, EventBridge or Firehose with a different envelope, and the two vocabularies of bounce subtype do not line up, so the reporting built on the old shape needs re-deriving before anyone trusts it. 8. Ramp instead of cutting over. You are a sending identity with no history and the placement you enjoyed was a property of somebody else's operation, so keep receipts and password resets on the proven path while the low-stakes traffic proves itself clean for several weeks. ## 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. On the day placement drops, who on our team diagnoses it, with which data, and has that person read a DMARC aggregate report before? 2. How often does support need the content of a specific message rather than its status, and what happens to those tickets when only the status is available? 3. At the volume we actually send, does the price gap fund the person who would own mail operations, or is it a saving that reappears as a salary line nobody wrote down? 4. Is our retention requirement a debugging habit or a written obligation — and if it is written, how many months, and who audits it? 5. Who sends the next marketing campaign, from which domain, and is there anything in the proposed arrangement that stops it sharing standing with the password resets? 6. If a plan price has been quoted to us, is it the current list or the terms an existing account happens to be grandfathered onto? 7. How many weeks would we be paying both vendors while the new identity warms, and has that overlap been budgeted rather than assumed away? ## A third shape of answer This is the pair where the crossover is most often mis-modelled. Teams look at the invoice at half a million messages, decide SES wins, and quietly commit to rebuilding the activity view, the stored message body and the support workflow that made Postmark worth paying for — which is the actual product, not the sending. If the thing you want is SES economics with a console that a support agent can use, a platform over your own AWS account is the shape that gives you both, and Wraps is one implementation of it. What it does not give you is Postmark's deliverability operation: you still need an AWS account and SES production access, an approval on AWS's timetable rather than ours, and the reputation that follows is yours to earn and yours to lose. Contacts and templates sit in our database rather than yours, our SDKs are TypeScript and Python only, and we are not SOC 2 certified. Wraps publishes this page. We are not one of the two vendors being compared here, and this note is on it because the tension above is one owning the AWS account actually addresses — not because it is on every page. ## Common questions ### Is Postmark's deliverability actually better, or is that marketing? It is real, and the mechanism is less mysterious than the marketing implies. Postmark keeps bulk mail off the transactional pool by design, removes customers who damage it, and monitors placement continuously with staff who know what they are looking at. A well-run SES account can reach the same place; the difference is that on SES nobody performs those three activities unless you hire someone to. You are buying operational discipline rather than a delivery secret. ### Does SES keep a copy of the emails I send? Not by default, and this surprises people who assume a mail service is also a mail archive. Events can be published to SNS, EventBridge or Firehose and from there into anything you like, but the rendered message body is not retained by AWS unless you deliberately configure archiving. If you want to answer what did that email say six months ago, that is a system you build, and building it after you need it is not possible. ### What are message streams and does SES have an equivalent? Streams are Postmark's enforced split between transactional and broadcast mail, so the two do not share sending reputation. SES has the raw materials — separate identities, separate configuration sets, separate dedicated addresses — and no enforcement whatsoever. The equivalent exists if you build and maintain it. The reason it matters is that the most common cause of transactional mail landing in spam is a campaign sent from the same reputation the week before. ### At what volume does SES clearly win on cost? Somewhere in the low hundreds of thousands a month the gap becomes large enough to fund real engineering, and past that it is not arguable. Below that, run the comparison including an AWS support plan and a realistic estimate of the operational work, because a great many SES migrations that looked like a saving turned out to be a transfer of cost from a vendor invoice to a salary line nobody wrote down. ### Can I use Postmark for transactional and SES for bulk? Yes, and it is a more common architecture than either vendor advertises. Use separate subdomains so DKIM keys, reputation and DMARC alignment stay independent, and keep the highest-stakes messages on the path with the best placement. The cost is two suppression lists, two sets of webhooks and a reconciliation nobody performs until a customer who unsubscribed receives a newsletter and complains. ### How much of my Postmark data can I actually take with me? Suppressions and templates come out cleanly, per stream, and are the parts everybody remembers. The rendered message archive is the part people forget, and it is the one with no equivalent waiting on the other side, so whatever you do not export is simply the last copy. Delivery events export within the retention window only. Plan the extraction as a task with an owner and a deadline before the account is cancelled, because a closed account is not a slow export — it is no export. ### What does a support agent use on SES instead of the activity view? Whatever you built. The usual shape is a configuration set publishing events to EventBridge or Firehose, landing in a store, indexed, behind an interface that accepts an email address and a date range. None of it is difficult and all of it is real work, and the version that shows delivery events but not the message body only answers half the tickets. Decide before the migration whether a support agent is a user of this system, because retrofitting them into it later is considerably more expensive than designing for them once. ### Does SES receive inbound mail the way Postmark does? Both can receive, and they hand you very different things. Postmark's inbound stream parses the message and posts structured fields to your webhook. SES receipt rules, available in a subset of regions, can drop the raw message into S3, invoke a Lambda, publish to SNS or reject it — and the parsing, the threading and the attachment handling are yours to write. If replies are a feature of your product rather than an afterthought, that difference is a subsystem rather than a configuration line. ### Is a dedicated IP worth buying on either side? Only above a volume floor that both vendors will tell you about if you ask, and for the same underlying reason: an address needs consistent traffic to hold a reputation, and a dedicated one sending sporadically performs worse than the shared pool it left. On Postmark it is gated behind the higher plans with a monthly minimum attached. On SES you can provision one at any volume, including a managed option that runs the warm-up schedule, which means it is easier to buy and just as easy to buy too early.