# Amazon SES vs Loops Source: https://wraps.dev/versus/amazon-ses-vs-loops Loops charges for contacts and sends as much as you like. SES charges for sends and does not know what a contact is. For a SaaS product with a large free tier, those two sentences decide the whole comparison. Loops made two opinionated choices that define this comparison: it charges on subscribed contacts rather than sends, and it puts product and marketing email in one tool with one contact list. SES made the opposite choice on both counts, charging per message and having no concept of a contact at all. Which of these suits you is not a matter of taste. It is a ratio: how many messages do you send per contact per month, and how much of your list is dormant? Work that out and the answer falls out of it. ## At a glance |   | Amazon SES | Loops | | --- | --- | --- | | What it is | Raw sending infrastructure from AWS | Product + marketing email for SaaS, priced per contact | | 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 at 1,000 contacts and 4,000 sends/mo. Paid plans price on subscribed contacts with unlimited sends — $49/mo in the 1K–5K band, $99/mo in the 5K–10K band, rising from there. | | Best for | Teams already on AWS with an engineer willing to own the plumbing. | SaaS teams who want lifecycle and transactional in one tool and never want to count sends again. | | 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. | You pay for contacts, not sends, so a large dormant free list stays on the bill. It is a product rather than a primitive, with less low-level control than an email API. | 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 pricing model, stated as the trade it is Amazon SES Per message, with a dormant contact costing exactly nothing. A product with fifty thousand signups and four thousand active users pays for the four thousand, because the other forty-six thousand are never sent anything. For freemium SaaS with a wide funnel, this is the single most consequential property of SES and it is frequently worth more than the low unit rate. Loops Per subscribed contact, with sending unlimited on top. A dormant contact costs the same as your most engaged one, so a large free-tier list is a permanent line on the invoice regardless of whether anything is sent to it. In exchange, a heavily engaged list costs nothing extra to mail more often, and the bill stops moving when your sending does. ### What unlimited sends changes about behaviour Amazon SES Every message has a marginal cost, and while the cost is tiny, the accounting is real: a weekly digest to a large list is a line item somebody can point at. Teams on SES tend to be slightly conservative about volume for this reason, which is occasionally good discipline and occasionally means a useful message does not get sent because nobody wanted to defend it. Loops Sending more costs nothing, which genuinely changes what teams do. Onboarding sequences get longer, digests get more frequent, re-engagement gets tried. That freedom is real value for a team iterating on lifecycle. It also removes the natural brake on volume, and the constraint that replaces it is your recipients' patience, which gives much less prompt feedback than an invoice does. ### One tool for transactional and marketing, or two Amazon SES SES sends whatever you hand it and knows nothing about the difference, which means the separation is yours to design and yours to forget. Most teams end up with SES for transactional and a second product for marketing, which is coherent and produces the usual seam: two suppression lists, two definitions of unsubscribed, and a reasonable chance of mailing someone who opted out of the other system. Loops Both in one product against one contact record, with transactional messages triggered by API and marketing campaigns composed in the UI, sharing a subscription state. That shared state is the strongest argument for the single-tool shape: unsubscribed means unsubscribed, once, everywhere, without an integration keeping two systems honest. For a small SaaS team this removes a whole category of embarrassing mistake. ### How much control you have over the message Amazon SES Total. SES accepts a raw MIME message if you want one, so headers, encoding, attachments, list-unsubscribe behaviour and multipart structure are all yours to determine. If you have a genuine requirement about how an email is constructed — a compliance header, an unusual content type, a specific threading behaviour — SES will do it and most products in this category will not. Loops Considerably less, by design. Loops is a product rather than a primitive: you work within its template model, its sending behaviour and its assumptions about what an email is. For the overwhelming majority of SaaS email that is fine and the constraint is invisible. It becomes visible the first time you need something specific and find that the product simply does not expose it. ### Who edits the email Amazon SES An engineer, in the codebase, through a deploy, because the rendering lives in your application. Templates are reviewable and versioned, which is a real benefit, and completely inaccessible to anyone who does not write code, which is a real cost. A founder who wants to change an onboarding subject line waits for the release cycle. Loops Anyone, in the editor, immediately, with a preview. The audience Loops is designed for is a small SaaS team where the person writing the copy is the founder or a growth hire, and the round trip through engineering is the bottleneck they are paying to remove. The trade-off is the usual one: the content is not in version control and not covered by your tests. ### Segmentation and the data behind it Amazon SES Whatever your database can express, evaluated by your own code, which is unlimited in principle and unavailable in practice to anybody without SQL access. SES receives a list of addresses and asks no questions. For teams with a strong data layer this is the more powerful option by a distance; for teams without one it is an empty room. Loops Contact properties and events synced from your application, with audiences built against them in the UI. Less expressive than SQL and enormously more accessible, which is the right trade for the product's audience. The limit people meet is usually a segment that needs a join or a computation the property model cannot express, at which point the answer is to compute it in your application and sync it as a property. ### Deliverability and the shape of the sender Amazon SES You are the sender, alone, and both the isolation and the responsibility are yours. A new identity is cold and needs warming, the metrics are in your console, and nobody will notice a problem on your behalf. The compensating benefit is that the reputation is an asset attached to an account you keep rather than a feature of a subscription you might cancel. Loops Loops operates the sending and carries the operational burden, which for a small team with no deliverability expertise is a genuine service rather than a checkbox. The corresponding exposure is the one every managed sender has: you inherit both the benefit and the risk of the pool, and the standing you enjoy is not portable to wherever you go next. ### What the exit costs Amazon SES Little, structurally. Domains and reputation stay with an account you keep, templates are already code, and the sending call is a few lines. Running a second provider from a separate subdomain and shifting traffic gradually is straightforward. This reversibility is undervalued at signup and extremely valuable on the day the decision is revisited. Loops Contacts and their properties export. Campaign history, the visual templates and the accumulated lifecycle configuration mostly do not, and the sending reputation was never yours. The code change is small because the API surface is small; the part that hurts is that the product was doing more for you than the code suggested, and all of that has to be rebuilt or rebought. ## Pros and cons, side by side ### Amazon SES Strengths - Fifty thousand signups and four thousand active users costs you four thousand users' worth of messages, because the meter never counts a person you do not contact. - Raw MIME is accepted, so a compliance header, an unusual content type or specific threading behaviour is a field you set rather than a feature request you file. - Segmentation is whatever your database can express, which for a team with a real data layer is unlimited rather than capped at what a property model can represent. - Templates are code, so they are reviewed, versioned and tested alongside the application that renders them, and reproducing production output locally is trivial. Trade-offs - There is no contact, no subscription state and no list, so the one flag that decides whether a person hears from you at all is a table you design and a check you remember. - Nothing composes, schedules, segments or measures a campaign, and the person who wanted to change a subject line now waits for the release cycle. - A new identity starts cold, the metrics live in a console nobody opens, and no one notices a rising complaint rate on your behalf. - Every message carries a marginal cost, which is tiny and is still an accounting line somebody has to defend before a weekly digest gets sent. ### Loops Strengths - Product and marketing mail share one subscription state, so unsubscribed means unsubscribed once and everywhere without an integration keeping two systems honest. - Sending more costs nothing, which genuinely changes behaviour: onboarding sequences get longer and re-engagement gets tried because nobody has to justify the marginal message. - Anyone can edit a message in the editor with a preview and publish it immediately, which for a small team removes the release cycle from the copy loop entirely. - The sending, the templates and the deliverability monitoring are operated by somebody else, which is a service rather than a checkbox for a team of five. Trade-offs - A dormant contact costs exactly what your most engaged one costs, so a wide free tier is a permanent line on the invoice for people nobody intends to email. - You work inside the product's model of what an email is, and the constraint is invisible until the day you need something it simply does not expose. - Removing the marginal cost also removes the natural brake on volume, and the signal that replaces it arrives as a complaint rate rather than as an invoice. - Campaign history, the visual templates and the accumulated lifecycle configuration mostly do not export, and the reputation was never attached to anything you keep. ## Pick in thirty seconds ### Choose Amazon SES if - A large share of your list is dormant, so paying per contact means paying for people you have no intention of emailing. - You send relatively few messages per contact per month, which is the ratio that makes per-send billing cheaper. - You need control over how the message is constructed — headers, encoding, attachments — that a product-shaped tool will not expose. - The engineering to own templates and segmentation already exists, and duplicating your user model in a vendor buys you nothing. ### Choose Loops if - Your list is small and engaged and you want to send to it far more often without a bill that grows every time you do. - The person writing the emails is not an engineer and the release cycle is the actual bottleneck. - Product and marketing email sharing one subscription state matters more than the flexibility of running two systems. - Nobody on the team wants to own deliverability, templates and a segmentation UI as a side project. ## 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. Understand that the thing you are giving up is a single flag. The whole argument for the one-tool shape is that a contact has one subscription state that both the product mail and the marketing mail consult. SES has no contact and no state, so the first thing to build is not a send path — it is the table that decides whether this person hears from you, plus the rule that transactional mail ignores it and marketing mail does not. 2. Export the mailing lists separately from the contacts. Per-list subscription is a different fact from whether somebody is subscribed at all, and a flat contact export flattens the two together. If people opted out of the changelog but not the product notices, that distinction exists only in the list membership, and losing it means either mailing people who opted out or silencing people who did not. 3. Move the message bodies out of the editor and settle the variable contract while you do it. A transactional message here is referenced by an identifier and rendered from a template the platform stores, filled from a data payload whose shape was whatever the editor happened to reference. Once the body lives in your repository that contract becomes explicit, and the fields nobody realised were being used are the ones that render blank. 4. Re-forecast with the marginal cost switched back on. Unlimited sending is not just a price — it is a behaviour, and teams on it send longer sequences and more frequent digests precisely because nothing pushes back. Count the messages you actually send today rather than the ones you planned, because that number is what meets a per-message rate, and it is routinely larger than the mental model of the person doing the comparison. 5. Rebuild the event triggers. Sequences here start from events your application posts to the platform, and those call sites keep succeeding against an account you are closing. Inventory them, decide what consumes those events afterwards, and cut them over in the same change as the sending rather than leaving a stream writing into nothing. 6. Set up DKIM on the SES side and keep the old sender live through one full cycle. The two sign with different keys through different records, and the standing you built belongs to the platform's pools rather than to your domain. Running both for a few weeks across a subdomain split is what turns a cutover into a ramp, and this is a place where a fortnight of patience is much cheaper than a month of throttling. 7. Start the production access application early, because it is the one gate somebody else controls. The questions are about how addresses were collected and what happens to a bounce, which the subscription-state work above has just made answerable in concrete terms. Answering it vaguely earns a request for more detail and another wait. 8. Decide who edits copy afterwards and write the answer down. This is the migration's real cost and it is not technical: the person who currently opens an editor and publishes is about to start filing tickets. Either that is acceptable, or a preview environment and an editing path is scope you are adding, and pretending otherwise is how a move that looked cheap becomes a standing complaint. ## 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. What fraction of our contacts received a message in the last ninety days, and what are we paying for the rest? 2. How many messages does an engaged contact actually receive from us in a month, and has anybody counted rather than guessed? 3. If unsubscribed had to be checked by our own code before every send, who writes that check and who verifies it is being called? 4. Who publishes copy changes today, and are they willing to open a pull request instead? 5. Do we send anything that needs a header, an encoding or an attachment behaviour a product-shaped tool would not expose? 6. Would our sending volume change if each message had a price, and is that change one we would actually want? 7. Who would be responsible for noticing a rising complaint rate, and how would they notice it? ## A third shape of answer The tension on this page is narrower than it first looks: most teams comparing these want the tooling Loops has and object specifically to paying for contacts who will never open anything. That is a solvable shape rather than a law of nature — a platform layer over your own AWS account can meter the platform and let AWS meter the sending, so contacts stop being the billed unit. Wraps does exactly that, with unlimited contacts on every tier. What it costs you is concrete: an AWS account and SES production access, which is an AWS approval on AWS's schedule rather than ours, SDKs in TypeScript and Python only, a template and campaign experience less polished than Loops', contacts and templates stored in our database rather than yours, and no SOC 2 certification. 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 ### At what point does contact-based pricing stop being worth it? Work out your sends per contact per month. If most of your list receives one message a month or fewer, per-send billing is dramatically cheaper and the dormant portion of the list is pure waste. If your engaged contacts receive several messages a week, unlimited sending starts to justify the per-contact rate quickly. The crossover is a ratio rather than a headcount, which is why comparing the two pricing pages directly tells you almost nothing. ### Can I delete dormant contacts to lower a contact-based bill? Yes, and on any contact-priced tool it is the first thing to do before deciding the price is unreasonable. The awkward part is that deletion is usually irreversible and takes the engagement history with it, so a contact you remove to save money is a contact you cannot later analyse or win back. Suppression where it is available is the gentler version. Either way it is a recurring hygiene task rather than a one-time cleanup. ### Does SES do marketing email at all? It sends whatever you give it, including a campaign, and it provides nothing that helps you compose, schedule, segment or measure one. There is no list, no audience, no editor and no report. Teams doing marketing on SES either run a separate marketing product alongside it or use a platform layer that adds those things on top. Building the campaign tooling in-house is a well-documented way to spend a quarter producing something your marketing person refuses to use. ### Can I keep transactional on SES and marketing on Loops? You can, and it partly defeats the reason to choose Loops, which is one contact record with one subscription state. Splitting reintroduces the reconciliation problem: two suppression lists and two ideas of unsubscribed. If you do it, use separate subdomains so reputations stay independent, and decide explicitly which system owns the opt-out — an unowned opt-out is how somebody who unsubscribed last month receives a newsletter this month. ### What does unlimited sending actually mean in practice? That the invoice does not move when volume does, within acceptable-use bounds any provider enforces. It is a real change in behaviour rather than a pricing gimmick: teams on unlimited plans send longer onboarding sequences and more frequent digests because nobody has to justify the marginal cost. The thing to watch is that the natural brake on volume is now your recipients' tolerance rather than your budget, and that signal arrives as a complaint rate rather than as an invoice. ### What replaces one shared subscription state on SES? A table you own and a discipline you enforce. The single flag is the reason the one-tool shape is attractive, and AWS has nothing corresponding to it: the suppression list understands bounces and complaints, not preferences. The working version is a subscriptions table, a rule that transactional sends bypass it and marketing sends consult it, and a check immediately before the call rather than when the audience was assembled. The gap between those last two is where somebody who unsubscribed on Monday receives a campaign on Tuesday. ### Do my per-list opt-outs survive a contact export? Not on their own. A contact export tells you whether somebody is subscribed; list membership tells you what they are subscribed to, and flattening the two loses the distinction the moment you import. Export the lists as a separate artefact and reconstruct the membership deliberately. This matters more than it sounds, because the group that opted out of one thing and not another is usually your most engaged segment, and getting it wrong is visible to exactly the people you can least afford to annoy. ### How do I preview an email before sending on SES? By building the preview, because AWS supplies none. What exists is a template API with token substitution and a console that will show you the template, neither of which tells you how a message renders in a real client. Teams that do this well render the message with realistic data in a development route, keep a set of saved payloads as fixtures, and send seed copies to accounts at the major mailbox providers before anything goes out. That is a normal amount of work and it is work that used to be a button. ### Will our sending volume change if messages start costing money? Usually yes, and it is worth deciding whether that is a feature. Unlimited sending removes the argument about whether a digest is worth it, so teams on it send more, and some of that extra sending is genuinely valuable while some of it exists because nobody had to defend it. Moving to a per-message rate reinstates the argument. Before comparing prices, count what you actually send rather than what you meant to send — that number is what meets the rate, and it is reliably higher than the estimate.