It works!
" }' ``` A successful send returns HTTP 200 with the SES message id: **Response:** ```json { "messageId": "0100018f2ab4c123-...", "id": "a1b2c3d4-..." } ``` ## Troubleshooting | Status | Error | Fix | | --- | --- | --- | | 401 | `Invalid API key` | Send the key in the `x-api-key` header (`Authorization: Bearer` also works). Check the key was not revoked; a brand-new key can take a minute to become active. | | 403 | `This API key is not allowed to send from that domain` | The `from` domain is not in this key's allowed domains. The response lists `allowedRootDomains`; use one of those or issue a new key. | | 403 | `From address is not a verified sender identity` | Complete domain verification in the dashboard for the `from` domain (DNS records must be live). | | 400 | `'subject' is required` and similar | Field validation failed — the error message names the exact field. See the [API reference](https://sendbunny.co/docs/send-email-api) for the full request contract. | | 422 | `Recipient is on the suppression list` | The recipient previously bounced, complained, or was manually suppressed. Remove them in dashboard → Suppression only if you are certain the address is deliverable. | | 502 | SES error message | SES rejected the send — most often sandbox mode (unverified recipient) or sending-quota limits. The message is passed through from SES. | ## Next steps - [Full API reference](https://sendbunny.co/docs/send-email-api) — every route, scope, and error. - [Interactive reference](https://sendbunny.co/docs/reference) — language-tab snippets generated from OpenAPI. - [For AI agents](https://sendbunny.co/docs/agents) — skill page. - [Email templates](https://sendbunny.co/docs/email-templates) — `templateAlias` + `data`. - [OpenAPI spec](https://sendbunny.co/openapi.json) — machine-readable contract. --- # HTTP API Canonical URL: https://sendbunny.co/docs/send-email-api One CloudFront host. One `x-api-key` header. One URL tree under `/v1`. The key's **scopes** decide which routes work. The machine-readable contract is [/openapi.json](https://sendbunny.co/openapi.json). Language-tab examples live on [/docs/reference](https://sendbunny.co/docs/reference). ## Base URL SendBunny is self-hosted. There is no shared API host. Your base URL is `https://It works!
" }' ``` 200: `{ "messageId": "Click the link below to reset your password.
" }' ``` A successful call returns `200` with a `messageId` from SES and an `id` for the send in your own ledger, which `GET /v1/emails/{id}` looks up later. A recipient on the account-wide suppression list, from an earlier bounce or complaint, returns `422` instead of silently dropping the message, so the calling code has something to log. ## Wiring the same path for a coding agent A coding agent that only needs to fire deploy notifications, receipts or alerts should get the same scoped key as any other backend service, not a broader grant borrowed from a human's session. An MCP grant limited to **Send mail** for one domain, or an API key scoped to `email:send` alone, lets the agent call `send_email` or `POST /v1/emails` without any path into the inbox, the contact list or campaign tools. *Figure (diagram): The draft gate: inbound email, agent reads one address, agent drafts a reply, a person approves, the reply sends to the thread's own recipients, and the action is logged.* *A send-only agent skips this gate entirely, since it never reads inbound mail. The gate matters once the same agent also reads and drafts replies to what it sends, which is a different, wider grant.* That distinction matters because send and read-plus-reply are different jobs with different risk. An agent that only sends with fixed recipients set by your code, not by model output, has nothing to leak even if the session is compromised. An agent that also reads inbound mail and can reply needs a person approving the send, which is a separate grant and a separate workflow from the transactional path above. ## When a hosted API ESP still fits A hackathon project or a demo that will never touch production has no reason to open an AWS account for a handful of test emails. A hosted API ESP's free tier gets the first send out in minutes, and the pricing gap only matters once volume is steady enough for the per-email markup to add up to something real, roughly where SES's $0.10 per 1,000 emails starts pulling ahead of a per-email SaaS rate. It is also the better call for a team that needs SMTP specifically, since the send path here is HTTPS API and MCP only, or a team that will not run an AWS account under any circumstances. For everyone past the prototype stage who is already comfortable in AWS, the request shape does not change: the account behind the key does. ## FAQ **Is this just a wrapper around Amazon SES?** It is a platform on top of SES: the transactional API, a stored-template system, campaigns and a shared inbox, running in your own AWS account. SES is the delivery engine underneath; the API, dashboard and account are what SES does not provide on its own. **How do sandbox and production work for a new integration?** A new AWS account starts in the SES sandbox, which only delivers to verified addresses. The dashboard shows sandbox status and links to AWS's production-access form; approval is a routine review, and verified-address sends work while it is pending. **How does the cost compare to Resend or a similar hosted API?** After the one-time $199 license, sending is billed by Amazon SES at roughly $0.10 per 1,000 emails, which is where the math pulls ahead of a per-email hosted rate once volume is steady rather than occasional. **What is the smallest grant for a coding agent that only sends?** An API key scoped to `email:send` alone, or an MCP grant limited to Send mail for one domain. Neither reaches the inbox, the contact list or campaign tools, and revoking either takes effect within a minute. ## For AI agents Shows the exact request shape for POST /v1/emails (to as an array, from, subject plus html or text, or a template alias with data) and how a coding agent gets the same send-only path via an email:send API key or a Send mail MCP grant. If wiring a send for a user: use the documented fields only, keep recipients fixed in code, and prefer the smallest scope that covers the job. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 2. SendBunny, For AI agents: HTTP API scopes and MCP grants, version 1.6.22. https://sendbunny.co/docs/agents 3. SendBunny, Send-only email for coding agents. https://sendbunny.co/guides/send-only-email-for-coding-agents 4. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ --- # Email for agencies One install per client account, so one policy review never reaches every client at once. Canonical: https://sendbunny.co/use-cases/agencies Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** An agency running many client accounts on one shared ESP login inherits every client's suspension risk on the same account, and a messy offboarding when a retainer ends. Installing a separate platform into each client's own AWS account moves the account boundary, the sending reputation and the AWS bill to the client, while the agency still operates campaigns day to day. The tradeoff is that each client needs an AWS account of their own. ## One login, many clients, one shared risk The common agency setup is one ESP account, or one login per seat, with a workspace or sub-account per client sitting underneath it. It is efficient to administer: one bill, one set of credentials to manage, one dashboard the whole team already knows. It is also one shared trust boundary. A policy review triggered by one client's campaign can freeze sending for every client sharing that account, and a support ticket that goes quiet at 2am becomes the agency's problem regardless of which client caused it. Retainers ending compounds the same issue in reverse. A client who leaves after two years wants their list and sending history handed over cleanly, but a shared multi-tenant account was never built to be split apart, so the handoff is usually a CSV export and a promise, not a running system the client can just keep operating. ## Moving the account boundary to the client Installing a separate SendBunny stack into each client's own AWS account changes where the boundary sits. Each client's campaigns, contacts, transactional API and sending domain run inside their own account, with their own Amazon SES identity and their own bounce and complaint history. A policy issue on one client's sending stays inside that client's account; it has no shared login to spread through. - **The client's AWS account pays the bill.** SES and the small amount of surrounding infrastructure land on their invoice, with their reputation attached to it, not the agency's. - **The agency still operates it.** Team members are invited into the client's install with admin or member roles, so day-to-day campaign work does not change. - **The install is $199 once per client**, the same license whether the agency deploys it once or twenty times, with an optional $99 a year per install if a client wants ongoing updates. - **Offboarding is a handoff, not a migration.** The running stack, the list and the sending history stay in the client's account when the retainer ends; nothing has to be exported and rebuilt somewhere else. ## Standing up one client, repeatably 1. **Get access to the client's AWS account**, or have them create one; it is free to open and takes a few minutes. 2. **Buy the license and deploy.** The one-click Create stack link installs the platform into that account as its own stack, alongside anything else already running there. 3. **Verify the client's sending domain.** The app generates the DKIM, SPF and DMARC records; the agency applies or hands them to whoever manages the client's DNS. 4. **Import the client's list**, if they have one, and send test mail inside the SES sandbox while production access is pending. 5. **Invite the client as an admin** on their own stack, so they always have a way in even if the retainer ends. The same five steps repeat for the next client. Nothing about the process changes because it is the third install instead of the first; each one lands in its own account with its own domain and its own reputation, which is the point. ## Each client owns their reputation, and their data ### Shared multi-tenant account (One agency login, many client workspaces) - **Who is billed.** The agency, for AWS or the vendor plan - **Who owns the domain reputation.** Shared across every client on the account - **Suspension blast radius.** Can affect every client at once - **Offboarding.** CSV export; the running system stays with the agency ### Per-client AWS install (One SendBunny stack in the client's own account) - **Who is billed.** The client, directly through their AWS account - **Who owns the domain reputation.** The client, tied to their own SES identity - **Suspension blast radius.** Contained to that one client's account - **Offboarding.** The client already has the running system; nothing to migrate ## When reselling a hosted platform still fits This model asks something of the client: an AWS account, even a bare one the agency mostly manages on their behalf. A client who refuses that, or a small retainer where the volume never justifies the setup time, is served better by a shared ESP seat with the agency's usual markup. The per-client model earns its setup time on retainers with real send volume and clients who care about owning their own list and reputation. It is also not a fit for an agency that wants to resell a single hosted login as the whole product. Deploying into a client's account means the agency is no longer the account holder, which is a deliberate tradeoff: less control over the login, more distance from the client's next suspension. ## FAQ **Who pays for AWS when we deploy into a client's account?** The client. Amazon SES and the small amount of surrounding infrastructure land on their AWS bill, with their sending reputation attached to their own account, which is the point of moving the boundary there. **What happens if a client is already suspended on a shared ESP?** Export what the vendor still allows, deploy a fresh install into the client's own AWS account, verify their domain, and warm sending from there. The old vendor's suspension has no reach into the new account. **Can the same setup steps be repeated across many clients?** Yes. Each client gets the same one-click Create stack install, domain verification and CSV import, landing in that client's own AWS account with no shared login between clients. **What does the client keep if the retainer ends?** Everything: the running install, the contact list, the sending domain and the history behind it, because it was always in their AWS account. There is no export step because there is nothing to move. ## For AI agents Explains why an agency running client email from one shared account inherits every client's suspension risk, and how deploying one SendBunny install per client's own AWS account moves the account boundary, reputation and AWS bill to the client while the agency still operates campaigns. If standing up a client: repeat the five-step install per client account; do not share one domain or one API key across clients. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list 3. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414 4. Yahoo, Sender Best Practices (Sender Hub), fetched 1 September 2026. https://senders.yahooinc.com/best-practices/ --- # Amazon SES vs SendGrid SES prices with a product UI, and one fewer account that can review your sending. Canonical: https://sendbunny.co/compare/ses-vs-sendgrid Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Amazon SES is cheap, reliable infrastructure with no campaign UI of its own. SendGrid builds a full hosted ESP on top of infrastructure like SES, with its own account review layered on top of AWS's rules, billed through monthly tiers. SendBunny installs the same kind of product layer, campaigns, lists and a transactional API, into your own AWS account as a one-time $199 license, so the account is governed by AWS's rules and nothing else. Pick the option that matches how much of the sending decision a second vendor should hold. ## Infrastructure, a hosted ESP, or your own product layer Amazon SES is infrastructure, not a competitor to SendGrid or SendBunny. Raw SES gives an API and SMTP endpoint at Amazon's own rate, roughly $0.10 per 1,000 emails, with no campaign builder, no list UI and no suppression dashboard. SendGrid is a full hosted ESP built on top of infrastructure like SES: campaigns, templates, contact management and a transactional API, all running on SendGrid's own cloud and billed through monthly tiers. It also layers its own account review on top, since SendGrid decides who keeps sending on its shared platform, separately from whatever AWS decides. SendBunny installs the same category of product, campaigns plus a transactional API, but into your own AWS account, as a one-time $199 license running on your own SES. There is no second vendor's review sitting on top of AWS's own rules, because there is no second vendor's shared platform in the first place. ## Feature by feature | Feature | Raw SES | SendGrid | SendBunny | | --- | --- | --- | --- | | Campaign / list UI | None | Full hosted UI | Full platform | | Pricing | Send cost only | Monthly tiers | $199 once + SES | | Idle month | About $0 | Plan floor still applies | About $0 platform cost | | Install | You build it | Signup | One Create stack click | SendGrid's hosted UI is a real product, built and maintained by a team that has run it for years, and that maturity shows in template tooling and analytics. SendBunny matches the shape of that UI, campaigns, lists, templates, a transactional API, while running it in an account already administered by you instead of a shared platform. ## What it costs as volume grows | | 10,000/mo | 50,000/mo | 1,000,000/mo | | --- | --- | --- | --- | | Raw SES | ~$1 | ~$5 | ~$100 | | SendGrid (Essentials and up) | ~$20/mo | ~$20/mo (to 50k) | ~$400+/mo (Pro tier) | | SendBunny on SES | ~$1 + $199 once | ~$5 + license | ~$100 + license | Mailgun and SendGrid list prices from their pricing pages, checked July 2026. SendGrid's monthly tiers cover hosting and support for its shared UI, and the price step from Essentials into the Pro tier at higher volume is a large jump relative to what SES itself charges for the same emails. SendBunny's cost is the license amortized once, plus SES's own per-email rate, so at a million emails a month the total sits close to $100 in send cost against a license already paid, versus SendGrid's few hundred dollars a month continuing indefinitely. ## Who can suspend your sending This is where the three options genuinely differ, not just in price. On raw SES and on SendBunny, the only party that can restrict sending is AWS itself, enforcing the same bounce and complaint thresholds it applies to every SES account. SendBunny does not add a second account it could suspend on top of AWS; it is software installed inside the AWS account already controlled by you. SendGrid adds a layer on top of that: an account review process specific to SendGrid's own shared platform, separate from whatever AWS decides about the underlying infrastructure. That review exists for a reason, since shared IP pools and a shared platform reputation mean SendGrid has to police who sends what, but it is a second gatekeeper that raw SES and SendBunny do not add. None of this makes SES accounts risk-free. AWS tracks bounce and complaint rates against its own reputation thresholds on every SES account, SendBunny's included, and can restrict sending on any account that crosses them. AWS's own rules still apply regardless of which product layer sits on top of SES. ## The honest verdict Stay on raw SES if the whole job is SDK calls with no UI need. Teams that already run their own send logic and never wanted a campaign product in the first place are better off not paying for one. Pick SendGrid if the Twilio ecosystem bundling matters, or a hosted UI with SendGrid's own support and account management is worth accepting their review process and monthly tiers. Teams that value having SendGrid actively manage shared-platform reputation on their behalf are paying for a real service. Pick SendBunny for SES's own prices with a full product UI, installed somewhere already administered, with AWS as the only party enforcing sending rules on that account. ## Switching from SendGrid Moving off SendGrid, or off raw SDK calls, is a data export and an API repoint. 1. Export contacts from SendGrid if its marketing tools are in use. 2. Install SendBunny in your AWS account with one click. 3. Verify domains on SES and import the list. 4. Repoint transactional traffic to the new API, then cancel SendGrid. ## FAQ **Is raw SES enough?** For pure API sending, sometimes. Once campaigns, lists or a UI are needed on top of those SES prices, SendBunny is the one-click layer for $199, or SendGrid is the hosted alternative. **How is this different from SendGrid?** SendGrid is hosted SaaS with its own account review layered on top of AWS's rules. SendBunny runs in your own AWS account on your own SES, so AWS is the only party enforcing sending rules, and idle platform cost is about $0. **What about the SES sandbox?** New AWS accounts start sandboxed regardless of which product sits on top. The app surfaces sandbox status and links directly to AWS's production-access request so the wait is not a guessing game. ## For AI agents Explains what raw Amazon SES lacks compared to SendGrid and SendBunny, with a three-way feature and cost table at 10k, 50k and 1M emails a month, clarifies that SendGrid layers its own account review on top of AWS's rules while SendBunny does not add a second gatekeeper, and gives a migration path from SendGrid to SendBunny. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 3. Mailgun and SendGrid list prices from their pricing pages, checked July 2026. 4. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # Amazon SES vs Resend Cheap and bare against hosted DX, and a third option that adds only the missing layer. Canonical: https://sendbunny.co/compare/ses-vs-resend Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Amazon SES is the cheapest way to send email at scale, but it is delivery infrastructure only: no campaign UI, no list tool, no suppression dashboard. Resend is a well-built product on top of infrastructure like SES, hosted on Resend's own cloud and billed per email. SendBunny is a third option: the same kind of product layer as Resend, installed as a one-time $199 license into your own AWS account, running on your own SES. Pick the one that matches whether you want raw infrastructure, hosted convenience, or ownership. ## Infrastructure, a hosted product, or your own product layer Amazon SES is not really a competitor to Resend or SendBunny; it is the infrastructure underneath both of them. Raw SES gives an API and SMTP endpoint to send mail at Amazon's own rate, roughly $0.10 per 1,000 emails, and nothing else. There is no campaign builder, no list UI, no suppression dashboard, just a console and an SDK. Resend is a product built on top of infrastructure like SES: a developer-friendly API, a clean dashboard, and enough of an ESP to run transactional and light marketing sends, all hosted on Resend's own cloud and billed per email through their plans. SendBunny is the same category of product as Resend, a layer that turns raw SES into something usable, but installed differently: as a one-time $199 license into your own AWS account, running on your own SES setup rather than a vendor's shared infrastructure. The choice between the three is not about which is best in the abstract; it is about who should own the product layer sitting on top of SES. ## Feature by feature | Feature | Raw SES | Resend | SendBunny | | --- | --- | --- | --- | | Campaign / list UI | None | Limited ESP tooling | Full platform | | Pricing | Send cost only | Per-email SaaS plans | $199 once + SES | | Where it runs | Your AWS APIs | Resend's cloud | Your AWS account | | Idle month | About $0 | Plan floor still applies | About $0 platform cost | | Install effort | You build the app | Signup | One Create stack click | Raw SES is the floor every option here shares: the same delivery infrastructure, the same Amazon reputation rules, the same per-email rate. What differs is who builds the product on top of it and where that product runs. ## What it costs as volume grows | | 10,000/mo | 50,000/mo | 1,000,000/mo | | --- | --- | --- | --- | | Raw SES | ~$1 | ~$5 | ~$100 | | Resend (Pro and up) | ~$20/mo (includes 50k) | ~$20/mo (includes 50k) | ~$650/mo (Scale) | | SendBunny on SES | ~$1 + $199 once | ~$5 + license | ~$100 + license | Resend list prices from its pricing page, checked July 2026. At low volume, Resend's plan floor and SendBunny's one-time license both add real cost on top of SES's own pennies. At a million emails a month, raw SES sending stays around $100 regardless of which product sits on top of it. Resend's hosted markup pushes the total toward $650 a month, while SendBunny's cost is still roughly $100 in SES charges plus a license already paid once. ## Who enforces the sending rules None of these three options removes AWS from the picture. Amazon SES tracks bounce and complaint rates against its own reputation thresholds and can restrict sending on any account that crosses them, including SES accounts running behind Resend or behind SendBunny. Choosing SendBunny over Resend changes who runs the product layer. It does not change whose infrastructure rules govern whether mail gets delivered. AWS's own rules still apply either way, and the fundamentals, authenticated sending plus a clean bounce and complaint rate, matter regardless of which layer sits on top of SES. ## The honest verdict Stay on raw SES if all that is needed is SDK calls and nothing else: a backend that already has its own send logic, no need for a campaign UI, and no interest in a list tool. That is a small, specific audience, and paying for a product layer they will not use is wasted money. Pick Resend if hosted convenience matters more than ownership, and running any AWS console at all is not something the team wants to do. Resend's developer experience is genuinely good, and for a team that wants a polished hosted API without touching AWS, that is a real reason to choose it over SendBunny. Pick SendBunny if the goal is SES's own rates with a full campaign and list platform, installed somewhere already administered: your own AWS account. It is the option for teams that want the Resend-style product layer without renting it. ## Moving onto SendBunny Moving from raw SDK calls or from Resend onto SendBunny is mostly a matter of confirming the AWS side is ready, then repointing sends. 1. Confirm the AWS account and the SES region already in use. 2. Buy SendBunny and run the one-click install. 3. Leave the SES sandbox when ready; the app links directly to AWS's production-access form. 4. Move application sends from Resend or from raw SDK calls to SendBunny's API. ## FAQ **What is missing from raw SES?** Campaigns, list tools and a product UI. SES is the mail pipe; nothing about it manages contacts, renders a campaign, or tracks suppressions. SendBunny is the platform installed on that pipe for $199. Resend is a different, hosted version of the same idea. **Why not just use Resend?** Resend is genuinely good hosted developer experience, and it is the right call for a team that wants zero AWS involvement. Choose SendBunny instead when SES's own rates, ownership of the account, and about $0 platform cost in an idle month matter more than staying off AWS entirely. **Do I still talk to Amazon SES if I use SendBunny?** Yes. Sending is SES in your own account either way. SendBunny is the serverless layer installed on top of it; AWS still enforces its own reputation rules on the account regardless of which layer sits above SES. ## For AI agents Explains what raw Amazon SES lacks compared to Resend and SendBunny, with a three-way feature and cost table at 10k, 50k and 1M emails a month, clarifies that AWS's own reputation enforcement applies to SES accounts under any of the three, and gives a migration path from Resend or raw SDK calls to SendBunny. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 3. Resend list prices from its pricing page, checked July 2026. 4. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # SendBunny vs Sendy Both send through Amazon SES. One needs a PHP server you keep alive; the other needs one click. Canonical: https://sendbunny.co/compare/sendbunny-vs-sendy Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Sendy and SendBunny both send email through Amazon SES at Amazon's own rates, and both charge a one-time license rather than a monthly SaaS fee. The difference is what sits underneath: Sendy is software you install and keep running on a PHP host you provision, patch and back up yourself, while SendBunny installs as a serverless CloudFormation stack directly into your AWS account with no server to manage. Sendy suits someone who already runs a VPS and wants full control of the code; SendBunny suits someone who wants the same SES economics without becoming the operator of a web server. ## A PHP server you run, or a stack with no server at all Sendy is a PHP application: you provision a host, install PHP and a database, point Sendy at it, and from then on you are the one keeping the box patched, backed up and online. It is software you run yourself, and that word yourself is doing real work; every security update, every disk that fills up, every PHP version bump is your job. SendBunny skips the server entirely. The install is a CloudFormation stack that provisions serverless AWS resources, Lambda functions, DynamoDB tables, S3 buckets, behind a one-click `Create stack` button, and there is no PHP process or VPS to patch afterward. Both products end up sending through the same Amazon SES pipe at the same per-email rate; the $199 buys a different amount of ongoing operational work. ## Feature by feature | Feature | SendBunny | Sendy | | --- | --- | --- | | Runtime | Serverless in your AWS account | PHP on a server you run | | Install | One `Create stack` click | Provision a host, PHP, and cron | | Cost in a quiet month | About $0 platform cost | The VPS bill keeps arriving | | License | $199 once | One-time Sendy license, plus hosting | The license fees land in similar territory; the recurring cost does not. A VPS able to run PHP reliably, with backups, typically runs somewhere from a few dollars to tens of dollars a month depending on the provider and the traffic it needs to handle, and that bill continues whether or not a single campaign goes out. SendBunny's serverless resources scale to near-zero cost when idle, so a quiet month costs close to nothing beyond whatever was actually sent through SES. ## Where the cost actually goes | | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny (Amazon SES) | ~$1 send | ~$5 send | ~$100 send | | Sendy plus VPS plus SES | VPS bill, plus the same SES send cost | VPS bill, plus the same SES send cost | VPS bill, plus the same SES send cost | Because both products send through Amazon SES, the per-email cost line is identical at any volume, roughly $0.10 per 1,000 emails. What changes is the fixed cost layered on top: SendBunny's fixed cost is a $199 license and near-zero infrastructure, while Sendy's fixed cost is a $199-class license plus a server bill that runs every month regardless of send volume, and that server needs someone watching it. ## The honest case for running your own box There is a real reason to choose Sendy over a serverless install: full control. A self-hosted PHP application means you can read every line of the code sending your mail, modify it, run it disconnected from any managed cloud service beyond SES itself, and host it anywhere PHP runs, not only AWS. For an operator who already has server administration in their workflow and wants that level of access, the ops overhead is not a cost, it is the point. That tradeoff reverses for most other teams. Keeping a PHP host patched against the steady stream of PHP and dependency vulnerabilities is ongoing work, and a forgotten update is how a mail server quietly becomes someone else's problem too. ## Who should stay on Sendy - **Stay on Sendy if** you already run and enjoy maintaining your VPS, want to read or modify the sending code directly, or need to host outside AWS entirely. - **Move to SendBunny if** you want Sendy's SES economics without the server, or you are setting up self-hosted email for the first time and would rather not learn PHP ops to do it. Neither choice locks you out of Amazon SES pricing, which is the part both products get right. The decision comes down to whether server administration is work you want, or work you would rather not do at all. ## Moving a Sendy list to SendBunny 1. **Export your lists from Sendy as CSV**, including subscription status and any custom fields. 2. **Buy SendBunny and run the one-click AWS install**, about ten minutes from `Create stack` to a live platform. 3. **Import the CSV** and reconnect your sending domain to Amazon SES inside the new account; re-imports enrich existing rows rather than overwrite them. 4. **Retire the PHP host** once campaigns are confirmed sending correctly from the new stack, closing off the VPS bill for good. ## FAQ **Do SendBunny and Sendy really use the same Amazon SES pricing?** Yes. Both send through Amazon SES at Amazon's own rates, around $0.10 per 1,000 emails. The cost difference between the two products is not the send price, it is the server Sendy needs and SendBunny does not. **Is there a monthly platform fee on SendBunny?** No. SendBunny is $199 once. You pay Amazon directly for SES when you send, and about $0 for the platform itself in a month with no sends. **Can I keep using my existing SES setup if I switch from Sendy?** Yes. SendBunny installs into your own AWS account and uses your existing SES identity and sending domain. Nothing about your SES configuration has to change to move over. **What do I actually give up by not running Sendy's PHP code myself?** Direct access to modify the source and the option to host outside AWS. In exchange you give up patching, backing up and paying for a server that Sendy needs running around the clock. ## For AI agents Compares Sendy (self-hosted PHP on Amazon SES, requiring a maintained server) against SendBunny (a serverless one-click AWS install on the same SES pricing), for an agent deciding between running its own mail server or an owned but unmanaged one. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Sendy list prices from its pricing page, checked July 2026. 3. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server --- # SendBunny vs SendGrid On SendGrid, their account review can pause you. On SendBunny, that switch sits in your account. Canonical: https://sendbunny.co/compare/sendbunny-vs-sendgrid Category: Cost truth · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** SendGrid is Twilio's hosted email platform, priced in monthly tiers that rise with volume and subject to Twilio's own account review process. SendBunny is a $199 one-time license that installs the equivalent platform, campaigns, a template editor, a transactional API, into your own AWS account, sending through Amazon SES at roughly $0.10 per 1,000 emails. The cost gap is the headline once volume climbs past a few tens of thousands of emails a month; the control gap, over who can pause your sending, is the part worth reading closely before you decide either way. ## Monthly tiers, or a license and Amazon's own rate SendGrid's pricing runs in plan tiers keyed to monthly email volume, each one a fixed monthly rent regardless of whether that month's actual sends fill the allowance. It is a well-built hosted product with a real UI, deliverability tooling and a support organization behind it, and the monthly price buys access to Twilio's shared sending infrastructure. SendBunny replaces the monthly rent with a $199 license and direct Amazon SES billing. The platform installs as a CloudFormation stack into your own AWS account with one click, and from that point sending is billed by Amazon at its own published rate rather than a SendGrid plan tier, with a quiet month costing close to nothing beyond the license already paid. ## Feature by feature | Feature | SendBunny | SendGrid | | --- | --- | --- | | Who can suspend you | You, subject to AWS policy | SendGrid's account review | | Where data lives | Your AWS account | Twilio SendGrid's cloud | | Pricing | $199 once, plus SES | Monthly email tiers | | Cost in a quiet month | About $0 platform cost | The plan floor still applies | ## What it costs at real volume | | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny (Amazon SES) | ~$1 | ~$5 | ~$100 | | SendGrid, Essentials tier (approx.) | ~$20/mo | ~$20/mo (Essentials covers to 50k) | ~$400+/mo (Pro tier) | Mailgun and SendGrid list prices from their pricing pages, checked July 2026. The two curves cross early and keep diverging. At 10,000 emails a month SendGrid's Essentials tier already costs around $20, roughly twenty times SendBunny's roughly $1 in Amazon SES send fees for the same volume. At a million emails a month, SendGrid's Pro-tier pricing runs into the hundreds of dollars, while Amazon SES itself runs close to $100, a gap SendGrid's markup exists to cover the hosted product and support around it. ## The part that matters more than the invoice SendGrid, like any hosted ESP, runs an account review process, and a compliance flag on a shared platform can pause sending for every customer behind it while the review runs. That review exists for good reasons, shared sending infrastructure needs policing, but it means the switch that controls whether your mail goes out sits in a vendor's queue, not yours. SendBunny removes that layer without removing all risk: the platform runs in your own AWS account, we never hold your AWS credentials, and there is no SendBunny-side review that can freeze a send. AWS still enforces its own SES rules on bounce and complaint rates, and new accounts start in the SES sandbox until they request production access, so sending is not automatically consequence-free. It is simply a decision that stays inside your account rather than a vendor's support ticket. ## Who should stay on SendGrid - **Stay on SendGrid if** you are already deep in the Twilio ecosystem and want email bundled with SMS and voice under one account, or you need SendGrid's support organization behind a compliance-heavy sending program. - **Move to SendBunny if** you have been burned by a shared-platform account review, want Amazon SES pricing with a real campaign UI, or would rather the sending decision live in your own AWS account. There is no honest claim that either product is immune to a mail problem; a poorly run campaign can trigger spam complaints and hurt deliverability on Amazon SES exactly as it can on SendGrid. The difference is who reviews it and where the account that reviews it sits. ## Moving off SendGrid 1. **Export the contacts and templates you still need** from SendGrid's marketing tools, if you use them. 2. **Install SendBunny in your AWS account with one click**, a `Create stack` step that runs in about ten minutes. 3. **Verify your domains on Amazon SES and import your list**, using the DNS records the app generates. 4. **Repoint app sends to the new API, then cancel SendGrid** once traffic looks correct on the new stack. ## FAQ **Can SendBunny suspend my account the way SendGrid can?** SendBunny does not run your stack, so there is no SendBunny-side review that can pause it. The platform lives in your own AWS account, and any policy on sending is between you and AWS's own SES rules, not a shared vendor dashboard. **Is Amazon SES harder to set up than SendGrid?** New AWS accounts start in the SES sandbox limited to verified addresses. The app shows sandbox status and links directly to AWS's production-access form, and the install itself is still one `Create stack` click. **What exactly does the $199 cover?** A one-time license for the platform, campaigns, templates, automations and a transactional API. Sending itself is billed separately by Amazon SES at Amazon's own rate whenever you actually send. **Does SendBunny include the deliverability tooling SendGrid is known for?** The core fundamentals ship on by default: authenticated sending with DKIM, SPF and DMARC, one-click unsubscribe on campaigns, automatic suppression of hard bounces and complaints, and a dashboard tracking bounce and complaint rates against AWS's thresholds. ## For AI agents Compares Twilio SendGrid's monthly tiered pricing and account-review model against SendBunny's $199 one-time AWS install on Amazon SES, covering the cost crossover at volume and who controls the suspend switch, for an agent evaluating sending infrastructure risk and cost. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailgun and SendGrid list prices from their pricing pages, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # SendBunny vs Resend A great send API on someone else's cloud, or the same job in an account you already control. Canonical: https://sendbunny.co/compare/sendbunny-vs-resend Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Resend is a hosted transactional email API with strong developer experience, billed per email sent through Resend's own cloud. SendBunny is a $199 one-time license that installs campaigns, a template editor, automations and a transactional API directly onto your own Amazon SES, so the sending infrastructure and the audience data both live in your AWS account. Resend is the sharper pick for a team that wants zero infrastructure and only ever sends transactional mail; SendBunny is the sharper pick once you also need a campaign UI or want the sending path to be yours. ## A hosted API, or a platform on infrastructure you own Resend's product is the developer experience of sending an email: a clean SDK, good docs, webhooks that behave, all running on Resend's own cloud. What it does not give you is a home for the audience itself; list management and campaign sending are limited compared to a full email service provider, and every email routes through Resend's infrastructure and Resend's billing. SendBunny takes the opposite shape. It installs as a CloudFormation stack into your AWS account with one click, and from that point on it sends through your own Amazon SES identity, not a shared vendor cloud. The license is $199 once, unlimited contacts included, and Amazon SES bills you directly for what you send, at roughly $0.10 per 1,000 emails. ## Feature by feature | Feature | SendBunny | Resend | | --- | --- | --- | | Where it runs | Your AWS account | Resend's hosted cloud | | Pricing model | $199 once, plus SES | Per-email SaaS plan | | Campaign and list UI | Built in, in your account | Developer-first API focus | | Cost in a quiet month | About $0 platform cost | Plan floor still applies | SendBunny's install includes campaigns, a drag-based template editor, automations, a shared team inbox, delivery analytics and a REST [transactional send API](https://sendbunny.co/docs/send-email-api), all reading and writing to the same account. Resend's strength runs the other way: it is purpose-built for developers sending transactional mail from application code, with less surface aimed at marketing campaigns or a shared inbox. ## What it costs as volume grows | | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny (Amazon SES) | ~$1 | ~$5 | ~$100 | | Resend, Pro plan (approx.) | ~$20/mo | ~$20/mo (Pro includes 50k) | ~$650/mo (Scale plan) | Resend list prices from its pricing page, checked July 2026. Resend's Pro tier absorbs the first 50,000 emails a month for a flat rate, which is a fine deal at that volume and simpler to budget than raw SES pricing. The gap opens at real scale: a million emails a month runs close to $650 on Resend's Scale plan, against roughly $100 in Amazon SES send fees plus the one-time SendBunny license already paid. The markup on hosted per-email pricing is the price of not touching AWS at all, and it grows with volume rather than shrinking. ## What you give up moving off a hosted API This is the honest tradeoff, not a footnote. Resend's SDKs, webhook reliability and documentation are built for one job and do it well, and a team that only ever sends transactional email, password resets, receipts, one-off notifications, may never need anything SendBunny adds on top. SendBunny's [send API](https://sendbunny.co/docs/send-email-api) covers the same from, to, subject, body and template-alias pattern, with suppression enforced automatically, but it is one part of a wider platform rather than the entire product. The other side of that tradeoff is what SES brings back: an AWS account you already pay for, no separate vendor relationship for email, and no per-email markup once volume climbs past what a Pro-tier plan covers. ## Who should stay on Resend - **Pick Resend if** you send only transactional email, want zero AWS involvement of any kind, and value a purpose-built developer API over a campaign UI. - **Pick SendBunny if** you already use AWS, want campaigns and transactional sending from the same account, or expect volume to grow past the point where per-email SaaS pricing stays reasonable. A team just prototyping, sending a handful of transactional emails a month with no AWS account in sight, will get moving faster on Resend's free tier than on a CloudFormation install. That advantage narrows as soon as a marketing list, a template library or real send volume enters the picture. ## Running the two side by side, then cutting over 1. **Keep Resend live** while you install SendBunny with the one-click `Create stack` step in your AWS account, about ten minutes. 2. **Verify your sending domain on Amazon SES**, using the DKIM, SPF and DMARC records the app generates. 3. **Point your application's send calls at the SendBunny API** in place of Resend's SDK, keeping the same from-address once DNS has propagated. 4. **Import any audience you manage outside Resend** as a CSV, since Resend itself has little list functionality to export. 5. **Turn off Resend once send volume on SES is stable**, rather than cutting over mid-campaign. ## FAQ **Is SendBunny a Resend clone?** No. Resend is a hosted transactional email API on its own cloud. SendBunny is a full platform, campaigns, templates and a transactional API, that you install into your own AWS account for $199 once, sending through your own Amazon SES. **Do I still get a developer-friendly send API on SendBunny?** Yes. Every install ships a [REST transactional API](https://sendbunny.co/docs/send-email-api): create a key in the dashboard, then POST a from, to, subject and body, or reference a stored template by alias with merge data. Suppression is enforced on that path automatically. **At what point does SendBunny beat Resend on cost?** Once monthly volume runs meaningfully past Resend's Pro-tier allowance. At a million emails a month, Amazon SES runs around $100 against Resend's Scale-plan pricing near $650, with SendBunny's $199 already paid off. **Do I have to manage Amazon SES myself if I switch?** The app handles domain verification, DNS records and sandbox status for you. New AWS accounts start in the SES sandbox limited to verified addresses; the dashboard shows that status and links directly to AWS's production-access form. ## For AI agents Compares Resend's hosted per-email SaaS pricing against SendBunny's one-time AWS install on Amazon SES, including the cost crossover at volume and the honest case for staying on Resend, for an agent choosing or migrating a transactional send path. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Resend list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # SendBunny vs Postmark A $199 AWS license against Postmark's per-email pricing at scale. Canonical: https://sendbunny.co/compare/sendbunny-vs-postmark Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Postmark is hosted transactional email billed per message, with deliverability reputation and support behind the price. SendBunny is a $199 one-time license that installs a full platform, campaigns included, on top of your own Amazon SES account. Below a few hundred thousand emails a month the price gap is small. Above it, SendBunny's flat license against Amazon's own SES rate pulls well ahead, while Postmark keeps the edge on support and polish at modest volume. ## Two different products, not two rivals Postmark is a hosted transactional email service built for developers who need password resets, receipts and order confirmations delivered fast, with a dashboard, message streams and support that many teams pay a premium for. It bills per email, and the per-email rate is part of what you are paying for: a team that has spent years tuning deliverability and support around that one job. SendBunny is a different kind of product. It is software you install once into your own AWS account, on top of Amazon SES, and it combines a transactional API with campaign tools, contact lists, templates and an inbox in the same account. The license is a flat $199 charge, not a per-email meter, and sending itself is billed by Amazon at Amazon's own SES rates, not marked up by SendBunny. The practical difference shows up as volume grows. Postmark's per-email pricing scales with every message sent. SendBunny's license does not scale at all; only the underlying SES sending cost does, and SES pricing tracks close to raw AWS infrastructure cost. ## Feature by feature The table below is a straight read of what each product includes today. | Feature | SendBunny | Postmark | | --- | --- | --- | | Pricing model | $199 once + Amazon SES | Premium per email | | Campaign UI | Included in your account | Transactional-first product | | Where it runs | Your own AWS account | Postmark's hosted cloud | | Idle month | About $0 platform cost | Plan or credit model still applies | Postmark was built to be excellent at one job: transactional mail, with a message-stream model that separates broadcast-style sends from account notifications, plus support that responds fast when a delivery problem needs a person. SendBunny adds a campaign and audience layer in the same account as the transactional API, which matters if you send both kinds of mail and would rather not run two separate tools with two separate logins. ## What it costs as volume grows | | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny (on SES) | ~$1 | ~$5 | ~$100 | | Postmark (list rates) | ~$15+ | ~$55+ | High hundreds and up | Postmark list prices from its pricing page, checked July 2026. The gap is driven by what each price includes. Postmark's per-email rate covers hosting, message-stream tooling and support staff, and stays close to flat per email regardless of how many you send in a month. SendBunny's cost is almost entirely the $199 license amortized once, plus Amazon SES's own per-email rate, which SendBunny does not mark up. At ten thousand emails a month the difference is a few dollars either way. At a million, it is the difference between roughly one hundred dollars and several hundred. ## The honest verdict Pick Postmark if deliverability reputation and hands-on support matter more to you than owning the stack. Postmark has spent years building a name for landing transactional mail reliably, and its support team is a real advantage when a delivery problem needs a person fast rather than a ticket queue. Teams sending a modest, steady volume of transactional mail, happy paying for that peace of mind and never wanting a campaign tool in the first place, are well served staying put. Pick SendBunny if your volume is heading into the hundreds of thousands or millions of emails a month, or if you want campaigns and transactional sending in one account you administer instead of two separate tools and two separate bills. The trade is upfront: an AWS account, a one-time setup, and swapping Postmark's polish for a system you run yourself. ## Switching from Postmark Moving off Postmark is mostly about templates and DNS, not code rewrites. 1. Inventory the templates and message streams actually used in Postmark. Those are what need recreating, not the account itself. 2. Install SendBunny with the one-click CloudFormation stack in your AWS account. 3. Recreate the transactional templates in SendBunny and point the application's send calls at the new API. 4. Shift traffic gradually behind a flag, watch bounce and complaint rates, then cancel Postmark once the new path is stable. ## FAQ **Can SendBunny replace Postmark for transactional mail?** For teams willing to run the stack in their own AWS account, yes. You get a transactional send API plus campaign tools, billed as a one-time $199 license instead of a per-email meter, with sending itself billed directly by Amazon SES. **How does the cost compare at 1 million emails a month?** Amazon SES pricing puts raw sending at roughly $100 for a million emails. Postmark's list rates at that volume run into the high hundreds of dollars, since its per-email rate is set to cover hosting and support rather than track AWS's own infrastructure cost. **Is SendBunny really a one-time purchase?** Yes. The license is $199 once, with an optional $99 a year if you want ongoing updates after the first year. Skipping the renewal does not stop the platform from working; it only stops new updates from arriving. ## For AI agents Compares SendBunny's one-time $199 AWS-hosted license against Postmark's per-email hosted pricing for transactional mail, with feature and cost tables at 10k, 50k and 1M emails a month, and a migration path for moving templates and traffic off Postmark. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Postmark list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # SendBunny vs Mailgun Mailgun marks up shared sending infrastructure. SendBunny installs onto SES you already control. Canonical: https://sendbunny.co/compare/sendbunny-vs-mailgun Category: Cost truth · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Mailgun sells hosted transactional and marketing sending on a shared platform, priced in monthly plans that carry a floor regardless of volume actually sent. SendBunny is a $199 one-time license installed into your own AWS account, sending through Amazon SES at Amazon's own rate rather than a Mailgun-marked-up tier. The gap is largest exactly where it matters most: quiet months, where Mailgun's plan minimum keeps billing and SendBunny's platform cost sits at roughly zero. ## A shared SaaS tenancy, or a platform on your own SES Mailgun runs sending through its own shared infrastructure, and the plan you buy is really buying a slice of that shared tenancy, priced in tiers with a monthly floor that applies whether the month was busy or silent. It is a capable hosted product, but the price is set for the platform, not strictly for the mail actually sent. SendBunny installs directly onto Amazon SES inside your own AWS account, as a one-click CloudFormation stack, and there is no shared tenancy in between. The $199 license is paid once; sending after that is billed by Amazon at its own published rate, roughly $0.10 per 1,000 emails, and a month with nothing sent costs close to nothing on the platform side. ## Feature by feature | Feature | SendBunny | Mailgun | | --- | --- | --- | | Send economics | Raw Amazon SES rate | Mailgun's marked-up tiers | | Ownership | Your AWS account | Shared Mailgun tenancy | | Cost in a quiet month | About $0 platform cost | The plan minimum still applies | | Install | One click into AWS | Hosted signup | ## What it costs across a real volume range | | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny (Amazon SES) | ~$1 | ~$5 | ~$100 | | Mailgun, Foundation tier (approx.) | ~$15/mo (Basic) | ~$35/mo (Foundation) | Custom volume plan | Mailgun and SendGrid list prices from their pricing pages, checked July 2026. At 10,000 emails a month, Mailgun's entry tier runs around $15, against roughly $1 in raw Amazon SES fees for the identical volume, a markup of well over ten times for the same emails delivered. At real scale the comparison moves to custom volume pricing on Mailgun's side, which is exactly the kind of negotiated rate that stops being transparent; SendBunny's cost at a million emails a month stays a predictable $100 in SES fees, on top of the $199 already spent. ## The month nobody talks about: the quiet one Plan-floor pricing is easiest to defend during a busy month, when the flat rate looks like a bargain against actual usage. It is hardest to defend during a quiet one, a slow season, a product between launches, a list that gets emailed twice instead of ten times, when Mailgun's minimum plan charge keeps arriving at full price for a fraction of the sending. SendBunny's cost structure inverts that: the license is sunk once, and a quiet month costs close to zero beyond it, because Amazon SES only bills for what actually goes out. That difference compounds for any team whose send volume is seasonal or bursty rather than a flat monthly number, which describes most marketing sending and a good share of transactional traffic too. ## Who should keep Mailgun - **Keep Mailgun if** you rely on its specific routing rules, inbound parsing, or webhook features and would need to rebuild them elsewhere, or you are locked into a negotiated volume contract that already beats list pricing. - **Move to SendBunny if** you are tired of paying a plan floor in quiet months, want raw Amazon SES economics with a real UI, or want campaigns and a transactional API from the same owned account. Mailgun's routing and inbound-parsing features are genuinely deep, and a workflow already built around them is a real switching cost, not just inertia. Weigh that cost against what a plan floor is actually charging for sending that never happens. ## Moving off Mailgun 1. **List the domains and webhooks you rely on** in Mailgun before starting, so nothing gets missed in the cutover. 2. **Install SendBunny with the one-click AWS deploy**, a `Create stack` step that runs in about ten minutes. 3. **Move DNS and Amazon SES verification, then import your contacts** using the DNS records the app generates. 4. **Repoint API calls to the new send path and retire Mailgun**, once traffic on the new stack looks correct. ## FAQ **Why is SendBunny's idle-month cost close to zero?** There is no monthly platform rent. SendBunny is $199 once, and Amazon SES only bills for emails actually sent, so a month with no campaigns costs close to nothing beyond the license already paid. **Is SendBunny only for transactional sending, like some Mailgun plans?** No. Campaign tools and a transactional send API ship in the same serverless install, so marketing and application sends share one owned account rather than splitting across products. **Do I share IP reputation with other customers the way I might on Mailgun's shared tenancy?** No. On SendBunny you send from your own AWS Amazon SES setup, and reputation and identities are managed inside your account rather than shared with other tenants on a vendor's platform. **How much markup does Mailgun actually charge over raw Amazon SES?** At 10,000 emails a month, Mailgun's entry tier runs around $15 against roughly $1 in raw SES fees for the same volume, list prices checked July 2026. The gap narrows in relative terms at high volume but Mailgun moves to custom pricing there rather than a published rate. ## For AI agents Compares Mailgun's monthly plan-floor pricing on shared sending infrastructure against SendBunny's $199 one-time AWS install on raw Amazon SES rates, including the idle-month cost gap, for an agent evaluating sending cost across variable or seasonal volume. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailgun and SendGrid list prices from their pricing pages, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # SendBunny vs Mailchimp Pay once and keep the list, or keep paying Mailchimp by the contact. Canonical: https://sendbunny.co/compare/sendbunny-vs-mailchimp Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** SendBunny is a $199 one-time license that installs a full campaign and transactional email platform into your own AWS account, sending through Amazon SES at around $0.10 per 1,000 emails. Mailchimp is a hosted platform priced by how many contacts sit on your list, whether you mail them or not. Mailchimp wins on template variety, native integrations, and hosted signup forms; SendBunny wins on cost at any real list size and on who holds the data. ## A list you hold, or a list you rent The difference is not features first, it is where the platform lives. SendBunny installs as a CloudFormation stack into your own AWS account with one click; the contacts, templates, campaign history and suppression list all sit in your DynamoDB tables and S3 buckets. Mailchimp is a rented seat on Intuit's infrastructure: your list, your sending reputation and your account status all live inside their systems, governed by their [Standard Terms of Use](https://mailchimp.com/legal/terms/). The pricing follows the same split. SendBunny charges once, $199, and never charges again for the platform itself; sending costs whatever Amazon SES bills, roughly $0.10 per 1,000 emails, with contacts unlimited and free to store. Mailchimp prices by the number of contacts on the account, active or not, and that number climbs into a new plan tier as your list grows even if your actual send volume stays flat. ## Feature by feature | Feature | SendBunny | Mailchimp | | --- | --- | --- | | Where the list lives | Your AWS account (DynamoDB) | Mailchimp's servers | | Pricing model | $199 once, plus SES | Monthly, per contact | | Who can suspend sending | You, subject to AWS policy | Mailchimp, under its terms | | Cost in a quiet month | About $0 platform, plus any SES sent | Full contact-tier price | | Install | One click into your AWS account | Hosted signup | SendBunny's table above is the shorter list on purpose: campaigns, a template editor, automations, a transactional send API, a shared inbox and analytics all ship in the one install, but the surface area is aimed at owning the sending stack rather than matching every Mailchimp integration one for one. ## What it costs as the list grows | | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny (Amazon SES) | ~$1 | ~$5 | ~$100 | | Mailchimp, Standard tier (approx.) | ~$135/mo (10k-contact plan) | ~$450/mo (50k-contact plan) | Priced by contacts, not volume sent | Mailchimp figures are approximate list prices for its Standard tier, checked July 2026. The gap comes from what each side is metering. Amazon SES meters what you actually send, so a newsletter that goes to 10,000 people once a month costs about a dollar in send fees, and a quiet month costs nothing beyond the fixed $199 you already paid. Mailchimp meters the size of the list sitting in the account, so a business with 50,000 subscribers pays the 50,000-contact rate every month regardless of whether it sent one campaign or ten, and every unsubscribed or dormant row still counts toward that number until it is deleted outright. ## Who can stop your sending On SendBunny there is no vendor sitting between you and your list: sending runs through your own AWS account, we never hold your AWS credentials, and there is no SendBunny-side account review that can freeze a campaign mid-send. That does not mean sending is risk-free; AWS still enforces its own SES rules on bounce and complaint rates, and a new account starts in the SES sandbox until it requests production access. It means the switch that matters, the one that can shut off your mail, sits in your account rather than a vendor's support queue. Mailchimp's Standard Terms of Use give the platform the right to suspend accounts for policy violations, and because sending, list storage and campaign history all live on Mailchimp's side, a suspension takes all three away at once. Most suspensions are legitimate content or compliance calls, but the account holder finds out from inside the same dashboard that just stopped working. ## Who should actually stay with Mailchimp Honesty matters more than a sales pitch here, so this is where Mailchimp is genuinely the better fit. Its template gallery, journey builder, landing pages and hundreds of native app integrations are years ahead of any newcomer, and a marketer who lives inside Shopify or a CMS-driven signup flow will get more out of Mailchimp's ecosystem on day one than out of a platform built around AWS and an API. - **Pick Mailchimp if** you rely on its integration marketplace, need a hosted landing-page or signup-form builder today, or your team has no appetite for an AWS account at any price. - **Pick SendBunny if** you are tired of contact-tier billing, want the list and sending history to live in infrastructure you control, or need campaigns and a transactional API from the same account. There is a middle case too: a list that stays under a couple thousand contacts and sends rarely may sit comfortably on Mailchimp's free or entry tier, where the contact-based pricing has not yet started to bite. The crossover tends to happen once a list is large enough, or inactive enough, that the monthly contact charge stops matching the actual volume being sent. ## Moving off Mailchimp without losing history 1. **Export your contacts as CSV** from Mailchimp's audience settings, including tags and merge fields you rely on. 2. **Buy SendBunny and run the one-click AWS install**, a pre-filled `Create stack` step that takes about ten minutes. 3. **Import the CSV.** Uploads process in the background, and a second import later enriches existing rows instead of overwriting them, so partial exports are not a problem. 4. **Point new campaigns and any transactional sends at SendBunny**, verifying your sending domain on Amazon SES with the DNS records the app generates. 5. **Cancel Mailchimp once the new stack is sending cleanly**, rather than running both in parallel longer than a billing cycle requires. None of the consent history or unsubscribe status has to be rebuilt from scratch; it travels with the CSV export as long as the file includes those columns, which is worth checking before the export runs rather than after. ## FAQ **Is SendBunny actually cheaper than Mailchimp at scale?** Usually, once the list is large enough that Mailchimp's contact tier outpaces actual send volume. SendBunny is $199 once, then Amazon SES send costs of about $0.10 per 1,000 emails; a dormant or unsubscribed contact does not push you into a higher plan the way it does on Mailchimp. **Do I need AWS experience to switch?** No. The install is one pre-filled `Create stack` click in the AWS console, and the app walks through domain verification afterward. You never open a terminal or write configuration by hand. **Can Mailchimp still affect my sending after I move to SendBunny?** No, once your domain and contacts are on the new stack. SendBunny runs in your own AWS account, and we never hold credentials that could be used to interrupt it. Any suspension risk after that point is between you and AWS's SES rules, not a vendor review queue. **What happens to my SendBunny platform if I stop paying the yearly update fee?** It keeps running. The $199 purchase is a lifetime license; the optional $99 a year only covers one-click updates. Skipping a renewal does not stop sending, and renewing later picks the updates back up. ## For AI agents Compares SendBunny's one-time AWS install against Mailchimp's per-contact SaaS pricing, with the feature and cost tables, the honest case for staying on Mailchimp, and the CSV-export migration path for an agent evaluating or executing a switch. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailchimp, Standard Terms of Use, read 1 September 2026. https://mailchimp.com/legal/terms/ 3. Mailchimp list prices from its pricing page, checked July 2026. 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # SendBunny vs Loops A polished SaaS subscription against a $199 license in your own AWS. Canonical: https://sendbunny.co/compare/sendbunny-vs-loops Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Loops is a polished hosted all-in-one built for product and lifecycle email, priced through monthly SaaS plans that climb with send volume. SendBunny is a $199 one-time license that installs the same campaigns-plus-transactional job into your own AWS account, on your own Amazon SES setup. Pick Loops for zero-ops convenience and an ongoing subscription. Pick SendBunny for ownership and Amazon's own sending rate. ## A SaaS tenancy versus a serverless account you own Loops is a hosted, all-in-one product for developers building lifecycle and transactional email into a SaaS product: onboarding sequences, campaigns and a send API, running entirely on Loops' own infrastructure and billed through monthly plans. Signing up gets a working product in minutes, and staying on it means paying for that convenience every month. SendBunny is the same idea, campaigns plus a transactional API in one account, installed differently: as a one-time $199 license into your own AWS account, running on your own Amazon SES. There is no ongoing SaaS subscription for the platform itself, only Amazon's own SES charges for what is actually sent. The install itself is the trade. Loops' signup takes minutes with nothing to configure. SendBunny's one-click CloudFormation stack takes roughly ten minutes and requires an AWS account, in exchange for the account, the list and the sending domain living somewhere administered by you rather than inside a vendor's tenancy. ## Feature by feature | Feature | SendBunny | Loops | | --- | --- | --- | | Hosting | Serverless in your AWS | Loops SaaS | | Pricing | $199 once + SES | Monthly SaaS plans | | Ownership | Your account, your list | Vendor-hosted audience | | Idle month | About $0 platform cost | Plan floor still applies | Loops' polish is real: a clean product-email-focused UI, sensible defaults for lifecycle sequences, and nothing to install. SendBunny trades that initial polish for infrastructure ownership, and both products cover the same core job, campaigns plus a transactional send path for a product. Where the two diverge most is what happens to the account when a founder moves on or a company changes vendors. A Loops account is a login on Loops' servers, tied to whichever billing details created it. A SendBunny install is a stack inside a specific AWS account, transferable the same way any other AWS resource is: by handing over account access, not by asking a vendor to move data on your behalf. ## What it costs as volume grows | | 10k emails/mo | 50k emails/mo | 1M emails/mo | | --- | --- | --- | --- | | SendBunny (on SES) | ~$1 | ~$5 | ~$100 | | Loops (hosted plans) | Starter plan tier | Higher plan tier | Scale plan or custom pricing | Loops prices its plans by tier rather than a flat per-email rate, and moving into a higher volume band typically means moving to a higher plan. SendBunny's cost is the $199 license amortized once, plus whatever Amazon SES bills for the emails actually sent that month, at roughly $0.10 per 1,000. The gap is largest for a team whose send volume is uneven: a quiet month still sits inside whatever plan floor Loops has set, while a quiet month on SendBunny costs close to nothing. ## The honest verdict Pick Loops if zero infrastructure ownership is worth an ongoing subscription. Teams that want to sign up, ship product email the same day, and never think about AWS again are exactly who Loops is built for, and that convenience has real value for a small team moving fast. Pick SendBunny if product email volume is growing and an AWS account is not a dealbreaker. The ten-minute install buys a flat license instead of a plan that climbs with volume, and the list and sending domain sit in an account only you administer. The decision usually comes down to team shape rather than feature gaps. A two-person team shipping a first product often values Loops' speed to first send more than ownership. A team that already runs infrastructure on AWS, or expects volume to keep climbing, tends to value the flat license more the longer it stays on either platform. ## Switching from Loops The move is a contact export and an API repoint, not a rebuild of the product. 1. Export contacts from Loops. 2. Run the SendBunny install using the one-click AWS link from checkout. 3. Import the CSV, verify the domain, and reconnect transactional sends to the new API. 4. Cancel Loops once the new stack is stable and sending cleanly. ## FAQ **Is SendBunny as simple to start as Loops?** Signup is checkout plus one CloudFormation click, which takes about ten minutes, versus Loops' near-instant signup. An AWS account is required for SendBunny; after install, the platform runs in an account only you administer. **Does SendBunny scale the way Loops does?** Yes, though the mechanics differ. Loops scales by moving accounts to higher SaaS plan tiers. SendBunny stays serverless in your own AWS account, so a quiet month costs close to nothing on the platform side and a busy month tracks Amazon SES's own rate. **What does the SendBunny license cost?** $199 once. An optional $99-a-year subscription covers ongoing updates after the first year; skipping it does not stop the platform from working. **Does SendBunny cover lifecycle sequences the way Loops does?** It covers campaigns, templates and a transactional API, which is enough to run onboarding and lifecycle sends built as scheduled or triggered campaigns. Loops leans further into product-specific lifecycle tooling out of the box; SendBunny leaves more of that logic to your own application code. ## For AI agents Compares SendBunny's one-time $199 AWS-hosted license against Loops' hosted SaaS plans for product and lifecycle email, with a feature table and volume-based cost framing, plus a migration path for exporting contacts off Loops. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Loops list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # SendBunny vs listmonk Assemble the stack yourself for free, or pay $199 to skip straight to sending. Canonical: https://sendbunny.co/compare/sendbunny-vs-listmonk Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** listmonk is software you run yourself, free to license, built to send through Amazon SES or SMTP once you have provisioned a database, an application host and a reverse proxy for it. SendBunny is a $199 one-time license that installs the equivalent platform, campaigns, lists, a transactional API, into your own AWS account as a serverless CloudFormation stack, with no host to assemble. listmonk suits a team that wants to run the software itself and already has the operations habit; SendBunny suits a team that wants the same ownership without the DIY labor. ## Free software you assemble, or a platform that installs itself listmonk's license costs nothing, but the software still needs somewhere to live: a Postgres database, an application server, a reverse proxy in front of it, and a plan for backups and upgrades. None of that is difficult for someone comfortable running containers, but it is real, ongoing work that has to happen before the first campaign goes out, and it keeps happening every time a version bump or a security patch lands. SendBunny trades the free license for a paid one and removes that assembly step. The $199 install is a CloudFormation stack that provisions everything serverless, directly into your own AWS account, with a single `Create stack` click. There is no database server to size, no reverse proxy to configure, and no container host to keep patched; the tradeoff is that the software is not free, and it only runs on AWS. ## Feature by feature | Feature | SendBunny | listmonk | | --- | --- | --- | | Install path | One click into AWS | You provision the database, app and reverse proxy | | Ops model | Serverless, managed by the stack itself | You patch and scale the host | | Pricing | $199 once, plus SES | No license fee, plus your own infrastructure labor | | Cost in a quiet month | About $0 platform cost | The host you provisioned keeps billing | listmonk's own feature set is genuinely strong for its category: campaigns, subscriber management, bounce processing and SMTP or Amazon SES sending, all in software that you can read, fork and run anywhere containers run. SendBunny narrows that scope to AWS specifically in exchange for removing the assembly and upkeep entirely. ## Where the real cost sits | | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny (Amazon SES) | ~$1 send | ~$5 send | ~$100 send | | listmonk plus host plus SES/SMTP | Host bill, plus send cost | Host bill, plus send cost | Host bill, plus send cost | Send costs land in the same place either way, since both can route mail through Amazon SES at Amazon's own rate. What listmonk adds is the host: a database and application server sized for the list, running continuously, plus whatever time it takes to keep that host secure and up to date. SendBunny's $199 buys out that labor permanently rather than trading it for a lower sticker price. ## What running listmonk yourself actually buys you The case for listmonk is not really about the license fee, it is about control. Software you run yourself can be inspected line by line, hosted anywhere, and modified freely, and a team with existing container operations may already have the muscle memory to run it without treating it as a new burden. For that team, the free license is close to free in practice, because the operational cost was already sunk into how they run everything else. For a team without that muscle memory, the free license is misleading. The real cost shows up later, as an unpatched dependency, a database that needs a migration nobody scheduled, or an upgrade that breaks something at the worst time. That is the work SendBunny's $199 is priced to remove. ## Who should keep running listmonk - **Keep running listmonk if** you already operate containers comfortably, want to host outside AWS, or need to modify the sending code directly. - **Move to SendBunny if** you want the ownership listmonk offers without assembling and patching the stack yourself, or you are on AWS already and would rather pay once than run infrastructure indefinitely. Both paths end with contacts and sending history under your own control rather than a vendor's. The difference is whether you want to be the one operating the machinery that keeps it that way. ## Moving a listmonk list to SendBunny 1. **Export your subscribers from listmonk**, including list membership and subscription status. 2. **Install SendBunny with the one-click AWS link**, a `Create stack` step that takes about ten minutes. 3. **Import the CSV and verify your sending domain on Amazon SES** using the DNS records the app provides. 4. **Cut campaigns over to the new stack, then shut down the old host**, retiring the database and application server once sends look correct. ## FAQ **Why pay $199 if listmonk is free software?** The $199 is not for renting a SaaS, it is for a one-click serverless install in your own AWS account. It buys out the host provisioning, database setup and ongoing upgrade labor that a DIY listmonk stack still requires. **Does SendBunny lock me into a vendor cloud the way a hosted ESP would?** No. It runs entirely in your own AWS account, and lists and sending stay under your account from install onward. There is no SendBunny-side switch that can take the platform away. **Can I use Amazon SES with both products?** Yes. listmonk can send through SES or plain SMTP, and SendBunny is built around SES in your own account from the first install, so switching does not mean switching sending infrastructure. **How much operational work does listmonk actually require after setup?** Ongoing patching of the database and application host, monitoring disk and memory, and applying version upgrades yourself, work that never appears once on a SendBunny install because there is no server to maintain. ## For AI agents Compares listmonk (free, self-hosted software requiring a database, app host and reverse proxy you operate) against SendBunny (a $199 one-click serverless AWS install with the same Amazon SES send path), for an agent weighing DIY infrastructure labor against a paid but hands-off install. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. listmonk list prices from its pricing page, checked July 2026. 3. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server --- # SendBunny vs Klaviyo Profile-tier pricing against a flat license on your own AWS account. Canonical: https://sendbunny.co/compare/sendbunny-vs-klaviyo Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Klaviyo is an ecommerce-focused customer data platform priced by active profile count, with automation and predictive analytics built for Shopify-style stores. SendBunny is a $199 one-time license that installs an email platform, not a full CDP, into your own AWS account, with Amazon SES billing sends directly. Pick Klaviyo when the ecommerce depth and integrations are the point. Pick SendBunny when the list and the license matter more than profile-based pricing. ## A CDP priced by profile, or a license you own Klaviyo is built around a customer data platform: contact profiles enriched with purchase history, browsing behavior and predictive scores, wired tightly into Shopify and similar storefronts, and priced by how many active profiles sit in your account. The CDP depth is the product; email and SMS are the channels it sends through. SendBunny does one job: email. It installs into your own AWS account as a one-time $199 license, with campaigns, contact lists, templates and a transactional API running on your own Amazon SES setup. There is no profile-based pricing tier, because there is no CDP layer to price by profile in the first place. Klaviyo's own terms of service state that Klaviyo may terminate the agreement at any time without cause and without notice, a standard clause across hosted marketing platforms rather than something unique to Klaviyo. It is still a fact worth knowing before years of purchase history and predictive scores sit entirely in someone else's account. ## Feature by feature | Feature | SendBunny | Klaviyo | | --- | --- | --- | | Pricing driver | License once + SES volume | Active profiles / plan tier | | Ecommerce CDP depth | Email platform you own | Deep Shopify-centric CDP | | Where data lives | Your AWS account | Klaviyo's cloud | | Idle month | About $0 platform cost | Profile plan continues | Klaviyo's predictive analytics, win-back flows and Shopify-native segmentation are real advantages for a store that lives and dies by that kind of automation. SendBunny does not attempt to match that depth. It is a platform for teams whose actual need is owning campaigns, a list and transactional sending, not a full CDP. The transactional API is worth naming separately, since it is easy to miss in a feature table. Order confirmations, password resets and shipping updates run through the same account as the campaigns, so a store does not need a second vendor just to cover the transactional side while it decides what to do about marketing email. ## What it costs as volume grows | | 10k | 50k | 1M | | --- | --- | --- | --- | | SendBunny (SES, per month sent) | ~$1 | ~$5 | ~$100 | | Klaviyo (active profiles/mo) | ~$150 (10k profiles) | ~$720 (50k profiles) | Priced by profiles, not send volume | The two prices are not measuring the same thing, and that is the point. SendBunny's cost tracks how many emails are actually sent in a month, at Amazon SES's own rate. Klaviyo's cost tracks how many profiles are active in the account, regardless of whether all of them get emailed that month. A list of fifty thousand profiles emailed twice a month still pays Klaviyo's fifty-thousand-profile rate; on SendBunny it pays for roughly two sends to fifty thousand people, at about five dollars each time. ## The honest verdict Pick Klaviyo if the ecommerce depth and integrations are the actual point: predictive analytics, Shopify-native flows, and a CDP that ties purchases to segments automatically. Stores that build revenue-generating automations on top of that depth are paying for a real capability, not just a brand name, and SendBunny does not replace it. Pick SendBunny if the list and the license matter more than the CDP. That means an account you own, a flat $199 license instead of a bill that climbs with every profile added, and no dependency on staying inside a specific profile-count bracket to keep the price predictable. There is also a hybrid path some teams take: keep Klaviyo for the storefront-facing automations that genuinely earn its price, and route a separate newsletter or a transactional stream through SendBunny where the profile tax adds nothing. Nothing about the two products is mutually exclusive; they solve different problems for the same list. ## Switching from Klaviyo Moving off Klaviyo is a data export and a rebuild of the highest-value automations, not a full replatforming. 1. Export the profiles and segments still in active use from Klaviyo as a CSV. 2. Install SendBunny with the one-click AWS link. 3. Import the contacts and reconnect the sending domain on SES. 4. Rebuild the essential emails as templates and campaigns, then cancel Klaviyo if the CDP depth is not something the business actually uses. ## FAQ **Is SendBunny a full Klaviyo replacement?** Not for deep ecommerce CDP features. It replaces Klaviyo for teams whose email platform economics matter more than predictive analytics and Shopify-native profile taxes; the CDP layer itself is out of scope. **How do I pay for SendBunny instead of a profile plan?** SendBunny is $199 once. Sending runs through Amazon SES at Amazon's own rate. There is no active-profile tier, so a large list of quiet contacts does not raise the bill the way it would on Klaviyo. **Will my list stay in my own account if I switch?** Yes. Contacts live in your AWS account after import. SendBunny never holds credentials that could lock the list away from you, unlike a hosted account where Klaviyo's own terms allow termination without cause or notice. ## For AI agents Compares SendBunny's flat $199 AWS-hosted license against Klaviyo's active-profile pricing and ecommerce CDP depth, with feature and cost tables contrasting per-email and per-profile billing, and a migration path for exporting profiles off Klaviyo. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Klaviyo, Terms of Service, last updated 17 December 2025, read 1 September 2026. https://www.klaviyo.com/legal/terms-of-service 2. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 3. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # SendBunny vs Brevo Renting Brevo's marketing cloud against a $199 license in your own AWS. Canonical: https://sendbunny.co/compare/sendbunny-vs-brevo Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Brevo is a hosted marketing cloud priced on monthly plans and send credits, with SMS, chat and a sales pipeline bundled in for teams that want one vendor across channels. SendBunny is a $199 one-time license that installs campaigns, lists and a transactional API into your own AWS account, with sending billed directly by Amazon SES. Pick Brevo if that broader suite is the point. Pick SendBunny if email ownership and Amazon's own rates matter more than bundling. ## Renting a marketing cloud versus installing a platform Brevo is a hosted marketing cloud: email campaigns, SMS, live chat and a light sales pipeline, all running on Brevo's own servers and billed through monthly plans built around send credits and a contact cap. Paying keeps you inside that stack. SendBunny takes a narrower job, email specifically, and installs it into your own AWS account as a one-time purchase. Campaigns, contact lists, templates and a transactional API run in your account, on your own Amazon SES setup, and the $199 license does not recur unless you want ongoing updates. The difference is not only price. It is where the list, the sender identity and the sending reputation live: on Brevo's infrastructure, or in an AWS account you administer. That matters most for a team that sends from more than one product or brand. On Brevo, every sending domain and every automation sits inside one shared account with one plan tier covering all of it. On SendBunny, the account is yours from the start, so adding a second sending domain or a second brand is a DNS record in your own AWS console, not a negotiation about which plan tier now applies. ## Feature by feature | Feature | SendBunny | Brevo | | --- | --- | --- | | Hosting model | Your AWS account | Brevo's cloud | | Pricing | $199 once + Amazon SES | Monthly plans and send credits | | Idle month | About $0 platform cost | Plan continues regardless of volume | | Install | One click into your AWS | Hosted signup | Brevo's plan structure buys convenience: sign up, verify a sender, start sending, with SMS and chat available in the same account if you need channels beyond email. SendBunny buys ownership: the contact list and the sending domain sit in infrastructure you control, and there is no monthly bill sitting there during a quiet month. ## What it costs as volume grows | | 10,000/mo | 50,000/mo | 1,000,000/mo | | --- | --- | --- | --- | | SendBunny (on SES) | ~$1 | ~$5 | ~$100 | | Brevo (Starter and up) | ~$25+/mo | ~$65+/mo | Business or custom plan | Brevo list prices from its pricing page, checked July 2026. Brevo's plans are built around monthly send credits paired with a contact cap, so the bill climbs with either dimension even in a quiet month. SendBunny's cost is the $199 license amortized once, plus whatever Amazon SES charges for the emails actually sent, at roughly $0.10 per 1,000. A list that goes quiet for a month costs close to nothing on SendBunny. On Brevo, the plan keeps billing. ## The honest verdict Pick Brevo if the appeal is the broader suite: email, SMS, chat and a sales pipeline as one vendor and one login, and renting that convenience beats assembling it yourself. Teams that want Brevo as the system of record across marketing channels, not just email, are the ones the platform is actually built for. Pick SendBunny if email ownership and Amazon's own sending rates matter more than bundling. That means the list, the domain reputation and the sending path live in your AWS account, with no monthly plan tier tied to contact count and no dependency on Brevo staying in business or keeping your account in good standing. There is a middle case worth naming directly: a team that only ever sends email, has no interest in SMS or chat, but still wants a hosted signup with nothing to install. For that narrow case, Brevo's convenience is real and the ten minutes SendBunny's AWS install takes is a genuine cost, not a nitpick. Weigh that ten minutes against every month afterward. ## Switching from Brevo Moving off Brevo means moving the list and rebuilding a handful of templates, not migrating code. 1. Export contacts from Brevo as a CSV, including consent and subscription status. 2. Buy SendBunny and complete the one-click AWS install. 3. Import the CSV and verify the sending domain on SES. 4. Rebuild the essential emails as templates and campaigns, then cancel Brevo once the new stack is sending cleanly. ## FAQ **Is SendBunny a Brevo alternative for newsletters?** Yes, for the email side. You get campaigns you own in your own AWS account, billed as a one-time $199 license plus Amazon SES, instead of renting Brevo's cloud. Brevo's SMS, chat and sales-pipeline tools are not part of SendBunny. **What does use forever actually mean?** The $199 license is one-time and the platform keeps working indefinitely in your AWS account. Ongoing updates are a separate, optional $99-a-year subscription; skipping it does not stop the platform from sending. **Do inactive contacts cost me anything?** Not as a platform fee. Amazon SES bills only for emails actually sent, so a list full of quiet contacts does not push you into a higher monthly tier the way a Brevo plan built around contact caps and send credits can. ## For AI agents Compares SendBunny's one-time $199 AWS-hosted license against Brevo's hosted plans and send-credit pricing, with feature and cost tables at 10k, 50k and 1M emails a month, and a migration path for moving a contact list and templates off Brevo. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Brevo list prices from its pricing page, checked July 2026. 3. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # A Sendy alternative that skips the VPS The same SES economics, without a PHP server that is now your job. Canonical: https://sendbunny.co/alternatives/sendy Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Sendy got one thing right early: a one-time license and your own Amazon SES account beats renting a per-contact ESP on price alone. What Sendy's model does not include is the server. You are installing a PHP application, keeping its host patched, watching its SSL certificate, and being the one who notices when the VPS runs out of disk at 2am. A serverless install keeps Sendy's SES pricing idea and removes the server from the picture. ## What cheap actually includes Sendy is software you run yourself: a PHP application you install on a VPS, pointed at your own SES account. The license fee is genuinely low, and the sending rate is genuinely SES's own rate. What is not on that price tag is the box. Someone has to provision it, patch the operating system, renew the SSL certificate, take backups, and resize it when a campaign sends bigger than usual. That someone is whoever set it up, indefinitely. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | Sendy + VPS (approx.) | license + VPS | license + bigger VPS | ops time + SES + box size | The Sendy row is the honest shape of the cost: a license fee plus a server bill plus the ops hours nobody puts on the invoice. ## Sendy is good software, respectfully This is not an argument that Sendy is poorly built. It is stable, it has been around long enough to be trusted, and plenty of senders run it for years without drama. The honest difference between Sendy and an installed platform is not code quality. It is who is on call for the box: with Sendy, that is you; with a serverless install, there is no box to be on call for, because there is no VPS. - Stay on Sendy if you enjoy running your own PHP stack on a VPS and already have the operational habit of patching and monitoring it. - Stay if a small, cheap server genuinely costs you nothing in time, because your volume is light and the box rarely needs attention. - Move if the patching, the backups, and the occasional 2am alert are the part of this you would rather not do, and you are willing to click through a one-time AWS install to make the server disappear. ## What "free" actually costs **The real line item.** A $5 to $20 VPS looks like the cheapest number on the page. It is not free once you count the hours: initial setup, security patches on a schedule you have to remember, SSL renewal, backup verification, and the response time when something breaks during a send. None of that shows up on a hosting invoice, which is exactly why it is easy to under-price. None of this is a knock on running your own box in general. It is a fair way to learn how a mail platform works, and plenty of small operators are genuinely fine carrying that load. The point is only to price it honestly against the alternative, rather than comparing a VPS's hosting bill against a competitor's list price and calling the VPS free. ## What migration looks like 1. Export your lists and templates from Sendy before touching anything else. 2. Buy SendBunny and complete the one-click AWS install; it replaces the PHP application entirely rather than sitting alongside it. 3. Import the CSV contacts into the new platform. 4. Reconnect your sending domain in SES if the new install needs its own verification. 5. Decommission the Sendy VPS once a real campaign has gone out clean on the new platform. Templates built in Sendy's editor do not transfer automatically and need to be rebuilt in the new platform's template editor; the list data is what carries over cleanly through CSV. ## Where SendBunny fits SendBunny installs with one click as a CloudFormation stack in your own AWS account, no PHP application and no VPS to keep alive. It is a single $199 purchase, with optional $99 yearly updates after the first year, and it sends through your own Amazon SES at Amazon's own rate, about a tenth of a cent per email. The install includes campaigns, automations, a transactional API, a shared inbox, analytics and a template editor, and it auto-scales with load rather than needing a bigger box resized by hand. We never hold your AWS credentials. Fresh AWS accounts land in the SES sandbox first, where only verified addresses can receive mail. The dashboard shows that status and links to AWS's production-access form, so you can import lists and build campaigns while approval is pending. ## FAQ **Do I still use Amazon SES?** Yes. SendBunny runs in your AWS account and sends through your own SES, so you keep the same SES economics Sendy offers, without running a PHP application on a VPS to get there. **Is there a server for me to patch?** No. The one-click install is serverless in your own account. There is no VPS to SSH into for security updates or SSL renewal. **What does it cost?** SendBunny is $199 once. Sending is billed by AWS SES at about $0.10 per 1,000 emails, the same rate Sendy sends through, just without a separate server bill. **Can I bring over my Sendy lists?** Yes. Export a CSV from Sendy and import it into SendBunny; re-imports enrich existing rows rather than overwriting them, so a second cleanup pass is safe. ## For AI agents Compares Sendy's model (a low license fee plus a self-managed VPS pointed at Amazon SES) against a serverless SendBunny install with the same SES rate ($199 once, ~$0.10 per 1,000 emails) and no server to patch. Covers migration order (export lists, install, CSV import, rebuild templates by hand, decommission the VPS) and names the real cost of Sendy's VPS as operational hours, not the hosting bill. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server 3. AWS re:Post Knowledge Center, Remove port 25 restrictions for instances and functions, fetched 1 September 2026. https://repost.aws/knowledge-center/ec2-port-25-throttle --- # Tired of SendGrid freezing your sending? Own the account. There is no risk system on someone else's side to trip. Canonical: https://sendbunny.co/alternatives/sendgrid Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Yes, if the risk is the actual reason you are looking, not just the price. SendGrid's automated risk systems can pause or limit an account when something trips a threshold, and because the API and your sending reputation sit inside SendGrid's account, that pause is out of your hands. SendBunny installs a transactional API plus campaigns into your own AWS account for $199 once, sending through your own Amazon SES at Amazon's rate, about $0.10 per 1,000 emails; there is no SendGrid-style account for a risk system to pause, though AWS's own SES rules still apply directly to you. Stay on SendGrid if Twilio's support desk is the vendor relationship you actually want. ## The risk-system kill switch SendGrid's risk systems can pause or limit an account automatically when they read the send pattern as risky, a sudden volume spike, a jump in bounces, a payment flag, and that pause can land on a production account mid-send. You built your app on SendGrid's API and inherited whatever reputation the shared pool carries, but the switch that turns sending off sits on their side, not yours. Volume plans solve the price problem, if that is the problem you have. They do not change who holds the account. At some point the question stops being how much you pay per email and starts being who gets to decide whether your app can send at all. ## Who should stay on SendGrid Stay on SendGrid if Twilio's support desk and account management are the actual vendor relationship you want; that is a real reason to stay with a managed ESP and a legitimate one. Stay too if you will not create an AWS account under any circumstances. - Switch if you have been burned by an account freeze or a sudden sending limit you did not see coming. - Switch if you want transactional email plus campaigns in one app running in your own AWS account. - Switch if you want SES-level rates with an application layer already built around them. ## What volume actually costs SendGrid's Essentials and Pro plans price by monthly email volume in bands, so a jump in send volume can mean a jump to the next plan even before the risk systems get involved. SendBunny is a one-time $199 license, then Amazon SES for sending, about $0.10 per 1,000 emails, at $0 when the account is quiet. | | 10k emails | 50k emails | 1M emails | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | SendGrid (Essentials/Pro, approx.) | ~$20/mo | ~$20/mo | ~$400 to $900/mo | SendGrid figures are approximate list prices, checked July 2026. SendBunny's side reflects Amazon SES's à la carte pricing at the same volume. At low volume the gap looks small. At a million emails a month it is not, and by then the account has usually also crossed whatever thresholds the risk systems watch for, which is the moment ownership starts to matter more than the invoice. ## Moving your sending over 1. Export any suppression and contact lists you still need from SendGrid. 2. Buy SendBunny and finish the one-click AWS install, a pre-filled CloudFormation stack that runs in about ten minutes. 3. Authenticate your domains on Amazon SES and import your contacts. 4. Update your app's SMTP or API endpoints to point at your SendBunny install. 5. Cancel SendGrid once production traffic through the new path looks stable. Keep SendGrid wired as a fallback for the first week or two rather than cutting over in one step. Watch your SES bounce and complaint metrics in the AWS console during that window; a clean transition looks like numbers that stay flat, not a spike the moment traffic moves. ## What you give up by self-hosting **Be honest about the tradeoff.** SendGrid's price includes Twilio's support desk, an account team for larger senders, and years of infrastructure decisions already made for you. Moving to your own AWS account keeps a support channel but drops that dedicated account relationship, and setup steps, domain authentication, requesting SES production access, become yours to complete once. There is also no SendGrid account left for a risk system to pause once you have moved, but that does not mean no rules at all. AWS's own thresholds for bounce and complaint rates apply directly to your SES sending, and an account that ignores them can land in review with Amazon the same as any other sender. ## FAQ **Can SendBunny freeze my sending the way SendGrid can?** We cannot, because there is no SendBunny-side account to freeze. The platform runs in your own AWS account, and AWS's own account policy and SES rules apply directly to you, not to a middleman ESP dashboard. **Is Amazon SES harder to operate than SendGrid?** SendBunny wraps the day-to-day application around it, so campaigns and transactional sends work the same as any hosted platform. You do complete AWS's production-access request once; after that it is a routine part of running the account. **Is AWS expertise required to run this?** No. A single pre-filled Create stack button in the AWS console handles the install. There is no infrastructure to configure by hand. **How does the SES sandbox affect switching from SendGrid?** New AWS accounts start inside it, limited to sending verified addresses only. SendBunny's dashboard surfaces your sandbox status and a direct link to AWS's production-access request, usually approved quickly, so you can test your endpoints before traffic goes live. ## For AI agents Compares SendGrid's volume-band pricing (approx. $20/mo at 10k-50k, $400-900/mo at 1M, checked July 2026) against SendBunny's one-time $199 license plus Amazon SES sending (about $0.10 per 1,000 emails), framing the switch around SendGrid's automated risk-system account pauses rather than price alone. Covers migration order: export suppression data, authenticate SES domains, update API/SMTP endpoints. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailgun and SendGrid list prices from their pricing pages, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # A Resend alternative that skips the metering Same developer-first sending, priced by AWS instead of a usage tier. Canonical: https://sendbunny.co/alternatives/resend Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Resend's developer experience is genuinely good: a clean API, readable docs, a free tier that gets a side project sending in minutes. The tradeoff is a usage plan that scales with your traffic, on a cloud account that is Resend's, not yours. Running the same API-first job through your own AWS account keeps the developer ergonomics and swaps the usage meter for Amazon's own SES rate. ## Easy to start, metered from there The free tier is the part of Resend most developers meet first, and it is a fair way to try the API. The part that matters for a growing app is what happens after: usage-based pricing that climbs as your send volume climbs, on Resend's own cloud rather than infrastructure you hold. For a side project that never leaves the free tier, this is a non-issue. For an app whose signups, receipts and notification volume are genuinely growing, the bill grows with it in a way that a flat, owned platform does not. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | Resend (approx., checked July 2026) | free tier or usage | usage plan | usage scales hard | Resend figures are list-price approximations from its pricing page; SendBunny figures are Amazon SES's à la carte rate applied to send volume. ## Who should stay on Resend If your app sends a small, steady volume that comfortably sits inside the free or entry tier, and you only ever want a hosted send API with a React email preview workflow and nothing else, Resend already does that job well. There is no reason to add an AWS account for a problem that is not costing you anything. - Stay if you will not open an AWS account under any circumstance. - Stay if all you want is a hosted send API and a React preview tool, with no plan to ever add marketing campaigns. - Move if send volume is climbing and the usage bill is climbing with it, or if you want your product's sending account to be one you administer rather than rent. ## Swapping the send client 1. Inventory every place your codebase calls the Resend API and every domain it sends from. 2. Purchase a SendBunny license, then walk through the one-click install so the platform lands inside your own AWS account. 3. Verify the same sending domain in SES so DKIM and reputation carry over cleanly rather than starting cold. 4. Update your SDK or HTTP client calls to SendBunny's transactional API. If you can, ship the change behind a feature flag rather than a hard cutover. 5. Remove the Resend API keys once production traffic has run clean on the new path for a stretch, not just a single test send. Templates and any client-side React email components you built do not migrate automatically; the API call changes, but the rendering logic in your codebase is yours to keep or rewrite either way. ## What you give up **The honest tradeoff.** Resend's polished dashboard, its React email tooling and its support channel are a real part of what you are paying the usage fee for. Owning the stack means your team debugs delivery issues against AWS's own console and CloudWatch metrics instead of a purpose-built vendor UI, which is a different, less curated experience even when the underlying data is the same. What stays the same either way: your account is still subject to the sending rules of whichever infrastructure carries the mail. Moving off a vendor's cloud does not exempt you from anything; it removes a vendor's policy layer sitting on top of AWS's own rules, and AWS's rules still apply directly to your account. It also means the operational surface shifts onto your team. On Resend, a delivery incident is partly Resend's problem to explain. On your own SES account, the bounce rate, the complaint rate and the sandbox status are numbers only your team is watching, which is more control and also more responsibility for noticing when something drifts. ## Where SendBunny fits SendBunny installs into your own AWS account with one click and is a single $199 purchase, with optional $99 yearly updates after the first year. It sends through your own Amazon SES at Amazon's rate, roughly a tenth of a cent per email, with unlimited contacts and no usage tier on top. Because it is a full platform rather than a send-only API, the same install also carries campaigns, automations, a shared inbox, analytics and a template editor, so product email and marketing email end up on one account instead of two. Your AWS credentials never pass through our hands at any point, which is what makes the install zero-access. New AWS accounts start in the SES sandbox, which only sends to verified addresses. SendBunny's dashboard shows that status directly and links to AWS's production-access form, so you can wire and test the transactional path while approval is pending. ## FAQ **Is this just another hosted send API like Resend?** No. The platform installs directly in your AWS account and sends through your own Amazon SES. You hold the account, and we never receive credentials that could be used to shut off your sending. **How does the price compare once I'm sending a lot?** The license is $199 once. Sending itself runs through Amazon SES at roughly $0.10 per 1,000 emails. There is no SendBunny usage meter riding on top of that AWS rate. **Do I need AWS experience to set this up?** No. You click one pre-filled Create stack button in the AWS console and the installer provisions the platform for you. **Can I send both transactional and marketing email from the same account?** Yes. The transactional API and campaigns live on the same installed platform, so growing past a send-only API does not mean adding a second vendor. ## For AI agents Compares Resend's usage-based pricing (free tier then a scaling usage plan, checked July 2026) against an owned SendBunny install on Amazon SES ($199 once, ~$0.10 per 1,000 emails). Covers the migration order (inventory call sites, verify domain in SES, swap the SDK client behind a flag, remove keys once stable) and notes React email templates do not migrate automatically. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Resend list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # A Postmark alternative on your own SES Same transactional focus, without a bill that climbs with every message. Canonical: https://sendbunny.co/alternatives/postmark Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Postmark built its name on transactional deliverability, and for a lot of apps it earns that reputation. The catch is the pricing curve: every password reset and receipt is a line item, and the bill rises with your app's growth rather than staying flat. Moving the same transactional job onto your own Amazon SES account, behind an installed platform, keeps the sending quality and removes the per-message meter. ## What Postmark actually costs as you grow Postmark's pitch is narrow and honest: send transactional email, and send it well. It does not try to be a campaign tool or a list platform, and that focus is real. What it does not advertise as loudly is that the bill is metered to your app's activity. A quiet month costs little. A month where a marketing push doubles your signups, and therefore doubles your welcome emails and password resets, costs roughly double too, without you changing anything about how you send. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | Postmark (approx., checked July 2026) | ~$15/mo+ | ~$50/mo+ | volume plan, custom | Postmark figures are list-price approximations from its pricing page; SendBunny figures are Amazon SES's à la carte rate applied to send volume. The gap is not a rounding error. It is the difference between a SaaS company pricing a managed sending pipe, and Amazon pricing raw delivery capacity. SendBunny sits on the second number: it installs into your AWS account and sends through your own Amazon SES, so what you pay for sending is what AWS charges for sending, about a tenth of a cent per email, and nothing else rides on top of it. ## Who should actually leave, and who should stay Not every Postmark user has a reason to move. If your app sends a modest, steady volume of transactional mail and the bill is small enough that you never think about it, switching platforms for its own sake is wasted effort. The honest case for leaving shows up in a specific shape: your send volume is climbing, the invoice is climbing with it, and you would rather that curve follow AWS's raw SES rate than a SaaS markup on top of it. - Stay on Postmark if you refuse to hold an AWS account, or if you want a fully managed sender with zero AWS involvement and are happy paying for that. - Move if you are already comfortable with AWS, or willing to click through a one-time setup, and your transactional volume is large enough that the per-message tax has become a real number on the invoice. - Move if you also want campaigns and lists on the same platform, since Postmark deliberately does not do that and most teams end up paying for a second tool. ## Moving your streams over The migration is mechanical, not risky, if you do it in order and keep Postmark live as a fallback while you verify the new path. 1. List every Postmark stream your app actually sends: password resets, receipts, alerts, anything transactional. 2. Buy SendBunny and run the one-click AWS install. It provisions the platform as a CloudFormation stack in your own account. 3. Verify your sending domain in SES, and rebuild the templates or HTML you used in Postmark. This step is manual; nothing copies over automatically. 4. Point your app's send calls at SendBunny's transactional API. Keep Postmark wired as a fallback for a short window rather than cutting it off in one step. 5. Cancel Postmark once the new path's delivery looks clean in your own AWS metrics, not just in a spot check. What does not carry over automatically: template markup, any Postmark-side webhook wiring, and whatever suppression history sat inside Postmark's account. Rebuild suppression from your own bounce and complaint records rather than assuming a blank list on day one. ## What you give up leaving Postmark **Be honest about the tradeoff.** Postmark's support desk and its polished deliverability dashboards are a real product. Owning the stack means you read your own AWS console for bounce and complaint rates instead of a vendor's curated view, and when something breaks, you are the first line of debugging rather than a support ticket. That is a fair trade for a lower, flatter bill, but it is a trade, not a strict upgrade. What does not change: there is no vendor account sitting between your app and the send, which also means no vendor policy team that can suspend that account. Amazon's own SES rules still apply to how you send, and a bad complaint rate still gets reviewed by AWS the same way any SES sender is reviewed. Owning the stack removes a middleman, not the underlying rules of sending mail. ## Where SendBunny fits SendBunny installs as a CloudFormation stack in your own AWS account with one click, and it is a single purchase: $199 once, with optional yearly updates at $99 after the first year. It sends through your own Amazon SES at Amazon's rate, with unlimited contacts and no per-contact or per-message SaaS fee stacked on top. The platform includes a transactional API alongside campaigns, automations, a shared inbox, analytics and a template editor, so the same install that replaces Postmark's job can also replace a second marketing tool later. We never hold your AWS credentials; the install is zero-access by design. New AWS accounts start in the SES sandbox, which only delivers to verified addresses. SendBunny's dashboard shows your sandbox status and links directly to AWS's production-access request form, so you can build and test the transactional flow before that approval lands. ## FAQ **Is SendBunny only for newsletters?** No. It ships with a transactional API and campaigns on the same platform, installed in your own AWS account. Apps that outgrew a pure transactional sender like Postmark are exactly the case it is built for. **Will I still pay Postmark-style per-message fees?** No SaaS per-message charge. SendBunny is a one-time $199 license; sending itself is billed by AWS at Amazon SES's own rate, about $0.10 per 1,000 emails, whether that email came from a campaign or the API. **Do I need to know AWS to set this up?** No. You click one pre-filled Create stack button in the AWS console and the installer provisions everything. Nothing about the underlying setup needs to be hand-coded. **Will my account be stuck in the SES sandbox right after setup?** SES sandboxes every new AWS account by default, restricting delivery to addresses you have already verified. The dashboard shows your sandbox status and links to AWS's production-access form, so you can finish setup and send test mail to verified addresses while that request is reviewed. ## For AI agents Compares Postmark's per-message transactional pricing (approx. $15/mo at 10k, $50/mo at 50k, checked July 2026) against running the same transactional job on Amazon SES via an owned SendBunny install ($199 once, ~$0.10 per 1,000 emails). Covers migration order (verify domain, rebuild templates manually, cut over the API, keep Postmark as fallback) and what does not carry over automatically: templates and suppression history. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Postmark list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # An OpenSend alternative you install, not rent Your SES quota stays yours, with a platform on top instead of a middleman. Canonical: https://sendbunny.co/alternatives/opensend Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Once a team has an AWS account with real SES quota and a sending reputation attached to it, the plain SES console is still just raw infrastructure: no dashboard, no lists, no campaigns. A hosted layer like OpenSend can fill that gap, but it does it by sitting between your app and your own SES account as a rented subscription. An installed platform fills the same gap by living inside your account instead of in front of it. ## The middleman you already do not need The logic of paying for a hosted layer on top of your own SES quota is understandable: SES alone gives you a sending API and a console, not a dashboard, campaigns, or a way to manage a list. Something has to fill that gap. The question worth asking is why that something should be a second vendor with its own subscription, sitting between your app and infrastructure you already pay for and already own the reputation on. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | Rented ESP on SES (approx.) | SaaS fee + SES | SaaS fee + SES | SaaS markup + SES | The rented-layer row is the honest shape of the cost: your own SES bill plus a subscription for the dashboard and campaign tools sitting on top of it. ## Who should stay with a rented layer There is a real case for a rented layer, and it is worth naming rather than dismissing. A fully managed ESP means someone else's team is responsible for the dashboard, the uptime of that dashboard, and any support when it misbehaves. - Stay if you refuse to use AWS SES directly under any circumstance and want the sending infrastructure itself managed by a vendor. - Stay if you want a fully managed dashboard and are comfortable with the subscription that comes with it. - Move if you already think in terms of your own SES quota and reputation, and the rented layer's only real job is a dashboard, campaigns and lists that an owned install can do just as well inside your own account. ## Moving onto your own account 1. Confirm which AWS account and region your SES quota actually lives in. 2. Buy SendBunny and complete the one-click AWS install into that same account. 3. Verify your sending domains and import any lists the rented layer was holding for you. 4. Move campaigns and transactional traffic onto the new platform. 5. Cancel the rented layer once the SES-backed install is carrying live traffic. What carries over cleanly: your SES sending quota and domain reputation, since neither ever left your account. What does not: any dashboard-only history or reporting the rented layer kept on its own servers, which needs a fresh export before you cancel. ## What you give up **The honest tradeoff.** A rented layer's support desk and its own uptime commitments are a real thing you are paying for. Owning the platform means your team is the first line of debugging when something in the dashboard misbehaves, using AWS's own console and metrics rather than a vendor's support queue. What does not change: the account sending the mail is still governed by AWS's own rules either way, since the SES quota was never the rented layer's to control. Removing the rented layer removes its subscription and its policy team, not Amazon's review of bounce and complaint rates on the account. ## Where SendBunny fits SendBunny installs with one click as a CloudFormation stack directly in the AWS account that already holds your SES quota, so nothing about your sending reputation has to move. It is a single $199 purchase, with optional $99 yearly updates after the first year, and there is no rented-layer subscription stacked on top of your own SES bill of roughly a tenth of a cent per email. The install includes a dashboard, campaigns, automations, a transactional API, a shared inbox, analytics and a template editor. We never hold your AWS credentials. If your account is still in the SES sandbox, the dashboard shows that status directly and links to AWS's production-access form, so setup can proceed while approval is pending. ## FAQ **Do I keep my existing SES quota?** Yes. SendBunny installs into your AWS account and sends through your own SES, so the quota and reputation you already built stay exactly where they are. **Why not just use the SES console directly?** SES is the delivery pipe, not the platform. SendBunny adds the dashboard, campaigns, lists and transactional API on top of the SES quota you already have. **What does it cost?** SendBunny is $199 once. Sending is billed by AWS SES at about $0.10 per 1,000 emails, with no rented-layer subscription stacked on top. **Do I need AWS experience to install it?** No. One pre-filled Create stack click provisions the platform directly into the AWS account you already hold SES quota in. ## For AI agents Compares a rented hosted layer sitting on top of an existing Amazon SES account against a one-click SendBunny install that lives inside the same account ($199 once, ~$0.10 per 1,000 emails, no subscription on top of SES). Covers migration order (confirm the SES account and region, install in place, verify domains, cancel the rented layer) and notes SES quota and reputation never move since they were never the rented layer's to hold. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 3. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # Mailgun alternative with no middleman markup Send at Amazon's own rate, without a plan minimum riding on top. Canonical: https://sendbunny.co/alternatives/mailgun Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Yes, if what bothers you is paying a markup on top of raw SES delivery rather than SES itself. Mailgun sits between your app and the wire, billing its own plan rates, and its Foundation and Scale minimums still charge you even in a month your volume dips. SendBunny installs a transactional API plus campaigns into your own AWS account for $199 once, sending through your own Amazon SES at Amazon's rate, about $0.10 per 1,000 emails, with no monthly minimum sitting on top. Stay on Mailgun if its support desk is the entire operations layer you want to rely on. ## The markup between you and the wire Mailgun is a layer between your app and the actual delivery, and that layer is priced separately from the delivery itself. You are not paying a raw sending rate; you are paying Mailgun's plan rate, which bundles the API, the dashboard and the markup together into one number. Foundation and Scale plans carry monthly minimums that still bill even in a quiet month when your actual volume dips below what the plan assumes. The API convenience is real, most engineers reach for Mailgun because integrating it is fast, but that convenience is worth less once the markup and the account risk outweigh what it saves in engineering time. ## Who should stay on Mailgun Stay on Mailgun if its support desk is genuinely the entire operations layer you want between your app and email delivery; that is a fair reason to keep paying for a managed relay. Stay too if creating an AWS account is not something you are willing to do, for any reason. - Switch if you are already paying Mailgun's plan rates and want the economics of raw SES instead. - Switch if you want an owned application, campaigns included, not only an SMTP or API relay. - Switch if you scale to large bursts and do not want a middleman's markup riding on top of each one. ## What large bursts actually cost Mailgun's Basic and Foundation plans price by volume band with a monthly minimum attached, so a burst month costs more and a quiet month still costs the minimum. SendBunny is a one-time $199 license, then Amazon SES for sending, about $0.10 per 1,000 emails, with nothing owed when the account is idle. | | 10k emails | 50k emails | 1M emails | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | Mailgun (Basic/Foundation, approx.) | ~$15/mo | ~$35/mo | ~$400+/mo | Mailgun figures are approximate list prices, checked July 2026. SendBunny's numbers apply Amazon SES's à la carte rate to the same volume. At a million emails a month the gap is not close, and the plan minimums that applied at the lower volumes disappear entirely on SendBunny's side: you only ever pay for the emails that actually left the account. ## Moving routes, templates and suppression 1. Export the routes, templates and suppression lists you still need from Mailgun. 2. Buy SendBunny and complete the pre-filled one-click install in your AWS console, about ten minutes start to finish. 3. Authenticate your domains in Amazon SES, then import the contacts you exported. 4. Update your app's endpoints to point at your SendBunny install. 5. Cancel Mailgun once production traffic is stable on the new path. Nothing about routes or templates copies over automatically, which is why the first step says to export what you still need. Mailgun's inbound routing rules and any HTML templates built in its editor live in Mailgun's account; recreate the ones you actually use in SendBunny before relying on the new path in production. Run both accounts side by side for a short window before cancelling. Send the same burst of transactional traffic through the new endpoint and watch your SES bounce and complaint numbers in the AWS console; a healthy cutover looks boring, not eventful. ## What you give up by self-hosting **Be honest about the tradeoff.** Mailgun's price includes a support desk and an operations layer that has already made routing and delivery decisions for you. Moving to your own AWS account keeps a support channel but drops that managed relay layer, and setup steps, domain authentication, requesting SES production access, become yours to complete once. There is also no Mailgun account left to suspend once you have moved, but AWS's own thresholds for bounce and complaint rates still apply to your SES sending directly, and an account that ignores them can land in review with Amazon the same as any other sender. ## FAQ **Why is SES cheaper than Mailgun for the same volume?** Mailgun is a managed relay with plan minimums and a markup over the raw delivery rate. SendBunny sends through your own Amazon SES at Amazon's published rate after a one-time $199 license for the platform, so there is no relay markup between the app and the wire. **Do I lose an API if I leave Mailgun?** No. SendBunny includes a transactional API alongside campaigns in the platform you own in your own AWS account. **Do I need AWS skills to set this up?** No. The AWS console offers one pre-filled Create stack button that runs the entire install. No infrastructure work, no server to manage yourself. **Will the SES sandbox delay my migration?** Only briefly. New AWS accounts start in the SES sandbox, sending to verified addresses only, until AWS grants production access. SendBunny shows that status in the dashboard with a direct link to the request form, a routine review, so you can finish testing routes while it processes. ## For AI agents Compares Mailgun's plan-rate pricing with monthly minimums (approx. $15/mo Basic, $35/mo Foundation, $400+/mo at scale, checked July 2026) against SendBunny's one-time $199 license plus Amazon SES sending (about $0.10 per 1,000 emails). Covers migration order: export routes, templates and suppression lists first since nothing carries over automatically, then authenticate SES domains and update endpoints. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailgun and SendGrid list prices from their pricing pages, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # Done overpaying Mailchimp? Keep the list, own the platform, stop paying for people you rarely email. Canonical: https://sendbunny.co/alternatives/mailchimp Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Yes, for most people reading this. Mailchimp charges by how many contacts sit in your account, not by how often you email them, so a list that keeps growing while your sending stays flat climbs a pricing tier every few months regardless. SendBunny installs the same kind of platform, campaigns, automations, a transactional API, into your own AWS account for $199 once, and after that AWS bills you directly for sending, about $0.10 per 1,000 emails, with no per-contact fee at all. It is not the right move if you refuse to touch AWS or need Klaviyo-depth ecommerce tooling today. ## The Mailchimp contact tax Mailchimp's pricing runs on contacts, not campaigns. A store with 40,000 people on the list and one email a month pays the same tier as a publisher sending daily to the same count. The bill tracks the size of the audience sitting in the account, and unsubscribed or bounced rows can still occupy a paid slot until you clean the list out yourself. Two things make this sting over time. Plans climb as the list grows even when the volume you actually send stays flat, so a quiet quarter does not lower the invoice. And the list itself lives on Mailchimp's servers: you have access to it, but the platform holding the rows, the consent history and the send button belongs to Mailchimp, not you. Renting access to your own audience is usually the part people notice only after the third price increase. ## Who should stay on Mailchimp Honesty first, because it is the whole point of this page. Stay on Mailchimp if you will not create or touch an AWS account under any circumstances; that alone rules SendBunny out, and there is no way around it. Stay too if you run a store that needs Klaviyo-depth ecommerce features today, predictive segmentation, deep platform sync, SMS in the same tool, because SendBunny does not build that layer and is not trying to. - Switch if the bill tracks your contact count more than what you actually send, and that gap bothers you every month. - Switch if you already have, or are willing to create, an AWS account and click through a ten-minute install once. - Switch if you want campaigns and a transactional API in one platform you control, instead of two vendor relationships. ## What owning the list actually changes A list is not just a CSV of addresses. Owning one means holding the rows, the consent record showing who agreed and when, the suppression and unsubscribe history, the sending domain, and the ability to send, all at once. On a rented platform, the first three of those sit on the vendor's servers and the ability to send is subject to the vendor's own account policy. The domain is the one piece that was already yours. *Figure (diagram): The five pieces of owning an email list: contact rows, the consent record, suppression history, the sending domain, and the ability to send, with a rented platform holding three of the five and controlling the fourth.* *What moves with you when you leave a rented list for one in your own AWS account: the rows, the consent record and the suppression history, instead of staying behind on someone else's servers.* This matters most at the exact moment you decide to leave. Addresses without a consent record are not always a list you can lawfully mail from a new platform, and re-adding someone who unsubscribed on the old one is a fast route to a complaint rate that gets the new sender flagged too. ## What 10,000 contacts actually cost Mailchimp's Standard-tier pricing scales with the number of contacts on the account, not the number of emails sent in a month. SendBunny separates the two: a one-time $199 license for the platform, then Amazon SES bills you directly for what you actually send, about $0.10 per 1,000 emails, with nothing owed in a month you send nothing. | | 10k contacts | 50k contacts | 1M contacts | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | Mailchimp (Standard, approx.) | ~$135/mo | ~$450/mo | priced by contacts, not volume | Mailchimp figures are approximate list prices, checked July 2026; confirm your own tier before deciding. SendBunny's numbers use Amazon SES's à la carte pricing directly. The gap widens because the two are billed on different axes. Mailchimp charges more for more contacts, independent of whether you mail them. SES charges more for more emails sent, independent of how many rows sit idle in your account. A list with a long tail of people you rarely email costs Mailchimp the same either way; it costs SendBunny almost nothing until you actually send to them. ## Moving your list over 1. Export your contacts as a CSV from Mailchimp's audience settings. 2. Buy SendBunny and run the one-click AWS install, a pre-filled CloudFormation stack that takes about ten minutes. 3. Import the CSV. Running it again later enriches existing rows instead of wiping them out, so a partial or repeated import is safe. 4. Point your campaigns, and any transactional sends your app makes, at your new SendBunny install. 5. Cancel Mailchimp once you have confirmed the new stack is sending cleanly. What the CSV import does not do is bring your automations or your saved templates with it. Those steps above cover contacts and campaigns; nothing in them moves a customer journey or a designed template automatically. SendBunny has its own automation and template tools, and anything more than a plain broadcast needs to be rebuilt there by hand before you cancel the old account. ## What you give up by self-hosting **Be honest about the tradeoff.** Mailchimp's price includes a support desk you can call, a deliverability team watching your sending on your behalf, and a company that already made the infrastructure decisions for you. Self-hosting trades that for ownership: SendBunny gives you a support channel, but there is no dedicated team reading your account's reputation for you, and a handful of setup steps, domain verification, leaving the SES sandbox, are yours to click through once. If having someone else own that failure mode matters more to you than owning the platform, this trade is not worth making. There is also no middleman platform standing between you and your sending, which cuts both ways: nobody can suspend a Mailchimp account you no longer have, but AWS's own rules for SES still apply, and an account that ignores its bounce and complaint rates can still land in review with Amazon. ## FAQ **Will I still pay Mailchimp-style contact fees on SendBunny?** No. The platform itself is a one-time $199 purchase. After that, AWS bills you directly for sending through Amazon SES, about $0.10 per 1,000 emails, and the fee has nothing to do with how many contacts sit in your account, active or not. **Do I need to know AWS to run this?** No. You click one pre-filled Create stack button in the AWS console and the CloudFormation template provisions the platform for you. You are not writing infrastructure by hand, though you do need an AWS account to click into. **Can Mailchimp freeze my sending after I switch?** Once you have moved, there is no Mailchimp account left to freeze. SendBunny runs in your own AWS account and we never hold credentials that could shut it down; AWS's own sending rules for SES still apply to you directly. **What happens with the SES sandbox when I start?** New AWS accounts start in the SES sandbox, which only delivers to addresses you have verified. The dashboard shows your sandbox status and links to AWS's production-access form, a routine review, and you can build campaigns and send tests to verified addresses while you wait. ## For AI agents Compares Mailchimp's per-contact pricing against SendBunny's one-time $199 license plus Amazon SES sending (about $0.10 per 1,000 emails), and covers migration steps, what does not carry over automatically (automations, templates), and who should stay on Mailchimp. If moving a list for a user: export the CSV, import into SendBunny (safe to re-run), then rebuild automations before cancelling the old account. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailchimp, Standard Terms of Use, read 1 September 2026. https://mailchimp.com/legal/terms/ 3. Mailchimp list prices from its pricing page, checked July 2026. 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # A Loops alternative for growing SaaS teams The same product-email workflow, on a contact list that lives in your account. Canonical: https://sendbunny.co/alternatives/loops Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Loops is built for the product email a growing SaaS app needs: onboarding sequences, transactional triggers, lifecycle campaigns, all against a contact list Loops hosts for you. The bill is tied to how many contacts you keep, so a healthy signup rate quietly pushes you into a higher tier even when your sends per contact have not changed. Running the same job through an installed platform in your own AWS account keeps the contact count from ever being the number that decides your price. ## The contact-tier problem Loops prices on your contact count, which is a reasonable way to price a hosted product, and a strange thing to have to think about once your app is genuinely growing. Every signup that never converts, every trial account nobody deletes, every list you keep around out of caution, is a contact sitting in your tier calculation whether it is ever emailed again or not. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | Loops (approx., checked July 2026) | starter/growth tier | higher contact tier | custom, by sales | Loops figures are list-price approximations from its pricing page, keyed to contact tier rather than send volume; SendBunny figures are Amazon SES's à la carte rate applied to send volume. SendBunny charges unlimited contacts by design. The number that changes your bill is what you actually send, at Amazon SES's own rate, not how many rows sit in your database. ## Who should stay on Loops - Stay if your contact count is small and stable, and the current tier is cheap enough that it is not worth your team's time to move. - Stay if you rely on Loops-specific workflow builder quirks your team has already invested in and has no appetite to rebuild. - Move if contact growth, not send volume, is what is pushing your bill up, or if you also want campaigns and a transactional API on one owned platform rather than paying for product email separately from marketing email. Not for you if you refuse to open or use an AWS account under any circumstance; the honest alternative in that case is to negotiate the next Loops tier, not to force a migration you will resent. ## Moving your audience and flows 1. Export your contacts and write down every Loops automation and transactional trigger your product actually depends on. 2. Get a SendBunny license and click through the one-click AWS installer to put the platform in your own account. 3. Import the contact CSV. Re-imports enrich existing rows rather than wiping them, so a second, cleaner export later is safe to re-run. 4. Recreate the product emails and sequences that matter most first; leave rarely-triggered flows for a second pass. 5. Point your app at the new platform and cancel Loops once you trust what is running. Workflow logic built in Loops's automation builder does not transfer automatically; the trigger conditions and delays have to be rebuilt by hand against the new platform's automation tools, which is the part of this move that takes actual time. ## What you give up **The honest tradeoff.** Loops's workflow builder and its hosted analytics are designed specifically for product email, and that specialization is worth something. An owned platform gives you campaigns and automations too, but you are reading your own account's data and rebuilding sequences yourself rather than working inside a tool purpose-tuned for SaaS lifecycle email. What does not change: your account is still governed by the rules of whichever infrastructure sends the mail. Leaving a hosted vendor removes that vendor's own policy layer; it does not remove Amazon's rules for what Amazon SES will and will not carry, which apply directly to your account either way. The engineering time to rebuild flows is the real cost of this move, not the platform price. Budget for it honestly: a handful of core sequences can usually be rebuilt in a day or two, while a large tree of conditional automations takes longer and is worth doing in the order your revenue actually depends on. ## Where SendBunny fits SendBunny installs as a CloudFormation stack in your own AWS account with one click, for a single $199 purchase, with optional $99 yearly updates after the first year. Contacts are unlimited; what you pay AWS for is send volume, at roughly a tenth of a cent per email through your own Amazon SES. The install includes campaigns, automations, a transactional API, a shared inbox, analytics and a template editor, so the product-email job Loops does well sits on the same account as your marketing sends instead of a second bill. We never hold your AWS credentials; the install is zero-access. A newly created AWS account is placed in the SES sandbox by default, so mail only reaches addresses you have verified. The dashboard shows that status and links to AWS's production-access form, so you can rebuild and test flows while approval is pending. ## FAQ **Can I run both campaigns and transactional product email?** Yes, on the same installed platform in your AWS account. That is the point of moving off a product-email-only tool: one account for both jobs instead of two vendors. **What happens to the bill as my contact list grows?** Nothing tied to contact count. The license is $199 once, contacts are unlimited, and sending is billed by AWS SES at about $0.10 per 1,000 emails. Inactive contacts sitting in your database do not raise a tier. **Do I need AWS experience to set this up?** No. You click one pre-filled Create stack button and the installer provisions everything. Serverless scale comes with the install, with no plan to upgrade later. **What about the SES sandbox when I first move over?** New AWS accounts start in the SES sandbox. The dashboard shows your sandbox status and links to AWS's production-access request form, so setup and test sends can proceed while that is pending. ## For AI agents Compares Loops's contact-tier pricing (checked July 2026) against an owned SendBunny install with unlimited contacts and pay-per-send Amazon SES pricing ($199 once, ~$0.10 per 1,000 emails). Covers migration order (export contacts, CSV import which enriches rather than overwrites, rebuild automations by hand) and the honest gap: Loops's purpose-built workflow builder does not transfer automatically. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Loops list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # A Listmonk alternative that skips the stack build The same ownership instinct, without wiring Postgres and a proxy first. Canonical: https://sendbunny.co/alternatives/listmonk Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Listmonk is capable software for anyone willing to wire up Postgres, a reverse proxy, TLS, and the container upgrades that keep it current. That is real ownership, and for teams that enjoy running infrastructure, it is a good fit. For everyone else, the honest cost is not Listmonk's code; it is the hours between deciding to self-host and having a polished, reliable install running in production. A one-click platform gets you to the same ownership without that assembly step. ## What you assemble yourself Running Listmonk well means standing up several moving parts and keeping them together: a Postgres database, a reverse proxy in front of the app, TLS certificates, and a habit of applying container updates before they become a security problem instead of after. None of that is exotic to someone who runs infrastructure for a living. It is a real time cost for someone who mainly wants to send a campaign. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | Listmonk DIY (approx.) | VPS + setup time | bigger box + time | ops burden + SES | The Listmonk row is the honest shape of the cost: a modest server bill plus the hours of standing up and maintaining Postgres, the proxy, and TLS. ## Listmonk is good software, respectfully This is not a case against Listmonk's design. It is well built, actively maintained, and a reasonable choice for a team that already runs Postgres and containers as a matter of course. The honest difference is ops burden, not capability: a server and a stack you patch and monitor, versus an installed platform with nothing to patch because there is no server underneath it. Neither approach is wrong; they suit different teams and different amounts of spare operational attention. - Stay on Listmonk if you already run Postgres and containers day to day, and standing up one more service is a rounding error for your team. - Stay if you want to hand-tune every part of the stack indefinitely and consider that a feature, not a chore. - Move if you want the ownership Listmonk offers, campaigns, lists and a transactional API in your own account, without also taking on database administration and proxy configuration to get there. ## What DIY actually costs **Time is the real bill.** A small VPS running Listmonk might cost less per month than a one-time platform license. What it does not include is the setup weekend, the database backup strategy you have to design yourself, or the afternoon lost when a container upgrade breaks something and there is no support desk to call. That time has a cost even when no invoice shows it. The comparison only gets fair when both sides count the same things. A monthly VPS bill next to a one-time license looks like the VPS wins; add back the hours of database administration, proxy configuration and patch scheduling, priced at whatever your own time is worth, and the total shifts. ## What migration looks like 1. Export subscribers and lists from your Listmonk instance. 2. Buy the SendBunny license and run the one-click CloudFormation installer to bring the platform into your own AWS account. 3. Import the CSV contacts into SendBunny. 4. Recreate the segments and campaigns you still need; Listmonk's query-based segments do not carry over and need to be rebuilt as plain lists or tags. 5. Turn down the old servers once a real campaign has run clean on the new platform. Keep the old Listmonk instance running read-only until the first few campaigns on the new platform have gone out and looked right, rather than turning it off the moment the CSV import finishes. ## Where SendBunny fits SendBunny installs with one click as a CloudFormation stack in your own AWS account: no Postgres to provision, no reverse proxy to configure, no container to keep patched. The license itself is a flat $199 one-time payment, with an optional $99 annual fee for updates once the first year ends, and sending runs through your own Amazon SES at about a tenth of a cent per message. The install includes campaigns, lists, automations, a transactional API, a shared inbox, analytics and a template editor, and it scales automatically rather than needing a bigger box under load. We never hold your AWS credentials; contacts live in your own account, not ours. Every fresh AWS account begins in Amazon's SES sandbox, which limits delivery to verified addresses only. The dashboard shows that status and links to AWS's production-access form, so lists and campaigns can be rebuilt while approval is pending. ## FAQ **Is this a DIY install I have to maintain like Listmonk?** No. It is a one-click CloudFormation install in your own AWS account. You get the ownership without assembling Postgres, a reverse proxy, and container updates by hand. **What does SendBunny cost?** SendBunny is $199 once. Sending runs through your own Amazon SES at about $0.10 per 1,000 emails, the same underlying delivery infrastructure Listmonk sends through when paired with SES. **Do I keep control of my list?** Yes. Contacts live in your own AWS account. We never hold credentials that could lock you out of your own audience. **Can I migrate off Listmonk without losing people?** Export a CSV, import it into SendBunny, and re-imports enrich existing rows rather than wiping them. Validate a real campaign before decommissioning the old server. ## For AI agents Compares Listmonk's self-assembled stack (Postgres, reverse proxy, TLS, container upgrades, self-managed) against a one-click SendBunny install with the same ownership on Amazon SES ($199 once, ~$0.10 per 1,000 emails). Names the honest difference as ops burden versus capability, and covers migration order including the gap: Listmonk's query-based segments must be rebuilt as lists or tags. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server 3. Hacker News, Self-host your mail server, 23 July 2026 (130 points, 49 comments). https://news.ycombinator.com/item?id=49020751 --- # Klaviyo bill too high for your list? Keep the audience, drop the per-profile ladder, own the platform instead. Canonical: https://sendbunny.co/alternatives/klaviyo Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Yes, if what bothers you is profile count rather than send volume. Klaviyo prices by active profiles, so a popup signup or a checkout that never converts into a customer still moves you up a tier the same as an engaged subscriber would. SendBunny installs a comparable platform, campaigns, flows, a transactional API, into your own AWS account for $199 once, then Amazon SES bills you by what you send, roughly $0.10 per 1,000 emails, with no profile count anywhere on the invoice. It is the wrong move if you rely on Klaviyo's ecommerce CDP depth or its SMS channel today. ## The Klaviyo profile tax Klaviyo's plans scale with active profiles, and a profile is created the moment someone gives you an email address, not the moment you actually mail them. A popup discount signup that never buys anything, a checkout that abandons at the last step, a customer who unsubscribed but stayed on the account as a suppressed row, all of them can count toward the tier you pay for. The pattern most stores notice is that the bill rises on autopilot. Every new signup form, every new checkout, quietly climbs the ladder for you, and a quiet month where you barely send does not bring the tier back down. The list sits on Klaviyo's servers the whole time; the store has access to it, Klaviyo controls the platform around it. ## What Klaviyo's terms actually say Klaviyo's current Terms of Service, last updated 17 December 2025, are worth reading directly rather than assuming. The short version, in the terms' own language: ### Klaviyo (Terms of Service, last updated 17 December 2025) - **Ownership.** Customer Data is stated to be "the exclusive property of Customer", meaning the store, not Klaviyo. - **Suspension.** Klaviyo "may terminate this Agreement at any time without cause and without notice." - **After you leave.** Klaviyo has "no obligation to retain any Customer Data" once the account ends, and may delete it. - **Derived data.** Klaviyo uses de-identified "Derived Data" for its own product work, but states Customer Data is not used to train third-party foundation models. Read the second and third rows together. Ownership on paper and a termination clause with no notice period sit in the same document. Nothing here says Klaviyo behaves badly; it says the account, and the export you have not run recently, are two different things. ## Who should stay on Klaviyo This page is honest about the limits, not just the pitch. Stay on Klaviyo if you rely on its ecommerce CDP depth, predictive segments, deep platform sync, or its SMS channel bundled into the same tool, because SendBunny is an email platform and does not build any of that. Stay too if you will not create or use an AWS account under any circumstances. - Switch if your Klaviyo bill grew faster than your actual send volume did. - Switch if you want campaigns and a transactional API in one platform you administer, instead of renting the CDP layer to get email. - Switch if you already have, or are willing to create, an AWS account. ## What 50,000 profiles actually cost Klaviyo's Email plan bills by active profile count, independent of how many campaigns or flows you send in a given month. SendBunny splits the two apart: a one-time $199 license for the platform, then Amazon SES for sending, about $0.10 per 1,000 emails, at $0 in a month you send nothing. | | 10k profiles | 50k profiles | 1M profiles | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | Klaviyo (Email plan, approx.) | ~$150/mo | ~$720/mo | priced by profiles, not volume | Klaviyo figures are approximate list prices, checked July 2026; your store's actual tier depends on SMS add-ons and plan changes. SendBunny's side reflects Amazon SES's standard à la carte pricing. At 50,000 profiles the gap is not marginal. Klaviyo charges for the size of the audience regardless of send frequency; SendBunny charges for the mail that actually leaves the account. A store with a long tail of one-time buyers it rarely emails pays Klaviyo the same either way, and pays SendBunny almost nothing for that same tail. ## Moving your profiles over 1. Export profiles as a CSV from Klaviyo's audience or list settings. 2. Buy SendBunny and step through the one-click AWS install, a CloudFormation stack that is pre-filled and takes about ten minutes. 3. Import the CSV. Re-imports enrich existing rows rather than overwriting them, so it is safe to run more than once. 4. Rebuild your priority flows in SendBunny's automation builder and point transactional sends at the new install. 5. Cancel Klaviyo once you have confirmed the new stack is sending on its own. Flows do not travel with the CSV. Klaviyo's abandoned-checkout and post-purchase automations are built on Klaviyo's triggers and live in Klaviyo's builder; nothing in the import step recreates them. Rebuild the handful that actually drive revenue before you cancel, and treat deep Shopify or store sync as a separate decision from email ownership, since SendBunny focuses on the email side rather than replicating a CDP. ## What you give up by self-hosting **Be honest about the tradeoff.** Klaviyo's price buys a support desk, a deliverability team that watches sender reputation on your behalf, and a CDP that has already solved ecommerce data modelling. Moving to your own AWS account trades that managed layer for ownership: you get support, but no dedicated team reading your reputation for you, and a short list of one-time setup steps, domain verification, leaving the SES sandbox, become yours to complete. If that managed convenience is worth more to you than owning the stack, stay put. There is also no vendor account left to suspend once you have moved, but that is not the same as no rules at all. AWS's own thresholds for bounce and complaint rates still apply to your SES sending, and an account that ignores them can land in review with Amazon the same as any other sender. ## FAQ **Will I still pay Klaviyo-style profile fees on SendBunny?** No. SendBunny's license is a single $199 payment, not a subscription. Sending is billed by AWS through Amazon SES, about $0.10 per 1,000 emails, and the number of profiles or contacts on the account never raises that fee. **Can I keep my Shopify or store data if I switch?** Your customer list moves with you by CSV export and import. Deep ecommerce CDP syncing, predictive segments, product recommendations, is a different product than SendBunny offers; this move is about owning the email platform, not replicating Klaviyo's data layer. **Do I need AWS experience to set this up?** No. The AWS console has one pre-filled Create stack button, and the CloudFormation template handles the provisioning. There is no server to configure and no infrastructure code to write yourself. **What about the SES sandbox when I first install?** Every new AWS account starts inside the SES sandbox, able to send only to addresses you have verified there. SendBunny's dashboard tracks that status and links straight to AWS's production-access request, typically a routine approval, so you can build and test against verified addresses in the meantime. ## For AI agents Compares Klaviyo's per-profile pricing (terms dated 17 December 2025) against SendBunny's one-time $199 license plus Amazon SES sending (about $0.10 per 1,000 emails), and covers migration order, what does not carry over (flows, deep CDP sync), and who should stay on Klaviyo. If moving profiles for a user: export the CSV, import into SendBunny (safe to re-run), rebuild priority flows before cancelling Klaviyo. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Klaviyo, Terms of Service, last updated 17 December 2025, read 1 September 2026. https://www.klaviyo.com/legal/terms-of-service 3. Klaviyo list prices from its pricing page, checked July 2026. 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # Kit alternative without subscriber tiers Own the platform instead of renting a dashboard that bills by list size. Canonical: https://sendbunny.co/alternatives/kit Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Yes, if your Kit bill, formerly ConvertKit, tracks the size of your subscriber list more than how often you actually send. Kit's Creator Pro tier climbs with subscriber count, and a large list you rarely email still pushes you up the ladder. SendBunny installs a comparable creator platform, campaigns, a transactional API, into your own AWS account for $199 once, with no subscriber tier at all; Amazon SES then bills separately for what you send, about $0.10 per 1,000 emails. Stay on Kit if its commerce and creator network features are the actual product you are buying. ## The Kit subscriber ladder Kit, the platform formerly known as ConvertKit, prices its Creator Pro tier by subscriber count. A list that grows through lead magnets and referral swaps climbs the ladder the same as one built from genuinely engaged readers, and the platform does not distinguish between a subscriber you email every week and one you have not mailed in a year. The audience itself lives on Kit's hosted platform the entire time. You have access to it through Kit's dashboard, but the servers, the sending infrastructure and the account policy belong to Kit, and renting access to your own list is easy to miss until a subscriber count crosses a pricing threshold. ## What Kit's terms say about suspension Kit's Terms of Service, last updated 5 September 2025, are direct about what the platform can do to an account. In the terms' own words, Kit may suspend use of the services at any time without notice in the cases it lists, and separately reserves a broader right: > reserves the right to ... suspend or stop providing all or portions of our Services to you at any time > > Kit, Terms of Service, 5 September 2025 The terms do not address export rights after termination, which is a gap worth noticing on its own. Plan for the account to end on Kit's timeline, not yours, and keep your own current copy of the list rather than assuming you can pull one later. ## Who should stay on Kit Stay on Kit if its commerce tools and creator network are genuinely part of how you make money from the list, features SendBunny does not build. Stay too if using AWS, in any form, is not something you are willing to do. - Switch if your Kit bill tracks list size more than how often you actually send to it. - Switch if you want ownership of the platform itself, in your own AWS account, rather than a rented dashboard. - Switch if you need campaigns and a transactional API you control in one place. ## What a large list actually costs Kit's Creator tier bills by subscriber count and climbs again at each higher bracket, independent of how often you send an issue. SendBunny has no subscriber tier on its license; a one-time $199 payment covers the platform, and Amazon SES bills separately for what you actually send. | | 10k subscribers | 50k subscribers | 1M subscribers | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | Kit (Creator, approx.) | ~$119/mo | higher subscriber tier | priced by subscribers, not send volume | Kit figures are approximate list prices for its Creator tier, checked July 2026. SendBunny's numbers come from Amazon SES's à la carte rate applied to the same volume. Quiet months cost SendBunny close to nothing beyond the platform's fixed one-time price, while Kit's subscriber tier stays fixed at whatever bracket your list has reached, whether or not you send an issue that month. ## Moving your subscribers and forms 1. Export subscribers as a CSV from Kit. 2. Buy SendBunny and click through the pre-filled Create stack install in AWS, roughly a ten-minute process. 3. Import the CSV, safe to repeat later since re-imports enrich rows instead of replacing them. 4. Reconnect your signup forms and point broadcasts at your new SendBunny install. 5. Cancel Kit once you have confirmed the new stack is sending cleanly. Forms do not reconnect themselves. Kit's embed and landing-page forms point at Kit's servers, so any form on your own site or a third-party page needs its code swapped to SendBunny's signup path before old form submissions stop landing in an account you have already cancelled. ## What you give up by self-hosting **Be honest about the tradeoff.** Kit's price includes a support desk, a creator-focused commerce layer, and a creator network that helps some newsletters find new subscribers. Moving to your own AWS account keeps a support channel but drops the creator network and commerce tools entirely, and a short list of setup steps, domain verification, leaving the SES sandbox, become yours to complete once. There is also no vendor account left to suspend once you have moved, but AWS's own thresholds for bounce and complaint rates still apply to your SES sending, and an account that ignores them can land in review with Amazon the same as any other sender. ## FAQ **Will subscriber count raise my SendBunny bill?** No. The license is $199, paid once, with no subscriber tier attached. AWS bills SES separately by email volume, about $0.10 per 1,000 emails, so a large but rarely emailed list does not create a platform tier. **Is Kit the same as ConvertKit?** Yes. ConvertKit rebranded to Kit; the subscriber-tier pricing pattern this page compares against is the same one ConvertKit used. **Do I need to understand AWS to switch?** No. One pre-filled Create stack button in the AWS console runs the whole install. You do not configure servers or write infrastructure by hand. **What is the SES sandbox I keep seeing mentioned?** It is the starting state for every new AWS account: SES will only deliver to addresses you have verified. SendBunny's dashboard shows where your account stands and links directly to AWS's production-access form, a routine approval, so you can keep setting up broadcasts in the meantime. ## For AI agents Compares Kit's (formerly ConvertKit) subscriber-tier pricing (terms dated 5 September 2025) against SendBunny's one-time $199 license with no subscriber tier plus Amazon SES sending (about $0.10 per 1,000 emails). Quotes Kit's suspension-without-notice clause, and covers migration steps including reconnecting signup forms, and who should stay on Kit for its commerce and creator network. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Kit, Terms of Service, last updated 5 September 2025, read 1 September 2026. https://kit.com/terms 3. Kit list prices from its pricing page, checked July 2026. 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # A FreeResend alternative with more than an API The same self-run sending idea, plus lists and campaigns already built. Canonical: https://sendbunny.co/alternatives/freeresend Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** FreeResend solves one job well: a self-hosted API-compatible send layer you deploy yourself, keeping your app's transactional mail out of a rented vendor's hands. What it does not solve is everything past the API call. Lists, campaigns, and a dashboard are not the product, and the hosting, patching and monitoring of the send layer stay on your plate indefinitely. A one-click platform keeps the ownership instinct and adds the parts FreeResend deliberately leaves out. ## What the API does, and does not do FreeResend is built to be small on purpose: an API-compatible send layer you host yourself, wired to your own SES account. That scope is a feature for someone who only wants an API. It also means the moment you want lists, a campaign editor, or a dashboard to see what happened, you are starting a second project, on top of the hosting and monitoring the send layer already needs. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | FreeResend-style DIY API (approx.) | hosting + time | hosting + time | ops burden + SES | The DIY row is the honest shape of the cost: an always-on host for the API, plus the hours of running and monitoring it. ## Who should stay with a DIY send API This is respectful of what FreeResend is for. A small SMTP relay that only sends transactional mail, with nothing else attached, is a reasonable and minimal choice when that is genuinely all you need. - Stay if all you want is a tiny, self-hosted send relay and you have no plan to ever add campaigns or a dashboard. - Stay if you are comfortable keeping a small host running indefinitely, monitored, patched, and backed up. - Move if you outgrew the API-only scope: you want lists, campaigns and a dashboard on the same account, without wiring a second project to get them. ## What DIY actually costs **The always-on host.** A self-hosted send API is not free to keep running: a host bills every month whether it sent one email or ten thousand, and someone has to notice when it is down, patch the operating system, and rotate credentials. None of that is difficult work, but it is ongoing work, and it is a different job from writing the app that calls the API in the first place. Add the second project on top, the lists and campaigns most teams eventually want, and the honest total is two things to run: the send layer and whatever you build or buy to sit in front of it. Pricing FreeResend against a one-time platform license only on the API alone leaves that second project out of the comparison. ## What migration looks like 1. Note every domain and API call site your current send layer touches. 2. Purchase SendBunny and step through its one-click installer to land the platform in your own AWS account. 3. Verify your sending domain in SES and move transactional traffic first, since that is the highest-stakes path. 4. Import any lists you have been keeping separately and turn on campaigns once the API path is running clean. 5. Retire the old send-only host once production traffic has run stable on the new platform. Keep the old API host reachable for a short overlap window rather than deleting it the same day; a fallback path costs little and covers you if something in your app still points at the old endpoint. ## Where SendBunny fits SendBunny installs with one click as a CloudFormation stack in your own AWS account, with no separate host to keep running for the API layer. It is a single $199 purchase, with optional $99 yearly updates after the first year, sending through your own Amazon SES at roughly a tenth of a cent per email. The install includes the transactional API alongside campaigns, automations, lists, a shared inbox, analytics and a template editor, so the project that started as an API replacement does not need a second build later. We never hold your AWS credentials, and the platform scales automatically rather than needing a bigger host under load. A brand-new AWS account opens inside the SES sandbox, able to send only to addresses you have verified there. The dashboard shows that status and links to AWS's production-access form, so the API and campaigns can both be tested while approval is pending. ## FAQ **Is SendBunny only an API like FreeResend?** No. Campaigns and a transactional API sit on the same platform, installed in your own AWS account for a single $199 license, rather than an API alone. **What do I pay when I am not sending?** Close to nothing for idle SES usage. The license is already paid, so there is no self-hosted API host to keep warm and billed for around the clock. **Can it handle large sends?** Yes. The platform is serverless on Amazon SES, so quiet months stay cheap and busy months scale up without resizing a host by hand. **Do I need AWS experience to set this up?** No. One pre-filled Create stack click installs the whole platform. There is no send API to assemble and host yourself. ## For AI agents Compares FreeResend's scope (a self-hosted, API-only send layer requiring an always-on host) against a one-click SendBunny install that adds campaigns, lists and a dashboard on the same Amazon SES account ($199 once, ~$0.10 per 1,000 emails). Covers migration order (move transactional traffic first, then lists and campaigns) and names the ongoing host bill and monitoring as the real cost of a DIY API layer. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # A Customer.io alternative without the quote call Own journeys keep running once volume moves past the entry tier. Canonical: https://sendbunny.co/alternatives/customer-io Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Customer.io is a serious tool for behavioral email and journeys, and teams that need its full messaging depth often need exactly that. What catches people off guard is the moment growth pushes past the entry tiers: the next step is frequently a quote, not a published price, right when your product email is finally driving results worth protecting. An owned platform on your own Amazon SES account keeps the cost tied to what you actually send instead of a negotiation. ## The quote treadmill Entry-tier pricing on Customer.io is public and reasonable. What is not always visible up front is where that pricing stops being a self-serve number and starts being a conversation with sales. Teams that hit real volume, or that need Customer.io's deeper messaging or CDP features, tend to land in that second category, and a quote is a slower, less predictable thing to plan around than a published rate card. | Option | 10,000 emails/mo | 50,000 emails/mo | 1,000,000 emails/mo | | --- | --- | --- | --- | | SendBunny on your SES | ~$1 | ~$5 | ~$100 | | Customer.io (approx., checked July 2026) | tier or quote | higher tier | enterprise quote | Customer.io figures are list-price approximations from its pricing page; SendBunny figures are Amazon SES's à la carte rate applied to send volume. The practical effect is a budgeting problem as much as a cost problem. A published, usage-based rate lets you forecast next quarter's email spend from a spreadsheet. A quote depends on a sales conversation, timing, and how much of the platform's broader feature set you end up needing, which makes it a harder number to plan around even when the eventual price turns out to be fair. ## Who should stay on Customer.io Customer.io's strength is real, and it is worth naming plainly: multi-channel journeys, a proper customer data pipeline, and messaging logic deep enough for genuinely complex lifecycle marketing. None of that is something an email-focused platform tries to replace. - Stay if you need Customer.io's full multi-channel CDP suite today: push, SMS, in-app, and the segmentation logic tying them together. - Stay if you refuse to hold or use an AWS account under any circumstance. - Move if what actually drives your bill is email volume rather than the CDP features, and you would rather that cost track AWS's own SES rate than a sales-negotiated tier. ## Rebuilding the journeys that matter 1. Export your people and write down your highest-value Customer.io campaigns and transactional messages, not every flow you have ever built. 2. Buy SendBunny and complete the one-click AWS install into your own account. 3. Import your contacts as a CSV and verify your sending domain in SES. 4. Recreate the journeys that drive revenue first. Leave low-traffic or rarely-triggered flows for a later pass, or accept they will not be rebuilt. 5. Cancel Customer.io once the owned stack is carrying real production traffic, not just a test send. What does not carry over: Customer.io's segmentation logic and any non-email channels you were using. If your team leaned on SMS or in-app messaging inside Customer.io, that part of the workflow needs a separate plan; this move only replaces the email side. ## What you give up **The honest tradeoff.** Customer.io's segmentation engine and its multi-channel reach are a genuinely different product category from an email platform. Moving to an owned, email-focused install means giving up the parts of Customer.io that were never about email in the first place, in exchange for a bill that only tracks what you send. One thing does not change: there is still no email sent from your account without meeting the sending infrastructure's own rules. Owning the stack removes the vendor that could pause your account over a plan dispute; it does not remove Amazon's own review of bounce and complaint rates for accounts sending through SES. Weigh the trade honestly before you commit to it. If your team's daily work leans heavily on Customer.io's data pipeline and its cross-channel segmentation, replacing only the email layer may leave a gap somewhere else in the stack that now needs its own plan and its own budget line. ## Where SendBunny fits SendBunny installs into your own AWS account with one click, and there is no enterprise floor to clear: it is a flat $199 once, with optional $99 yearly updates after the first year. Sending runs through your own Amazon SES at roughly a tenth of a cent per email, with unlimited contacts. The install includes campaigns, automations, a transactional API, a shared inbox, analytics and a template editor, and we never hold your AWS credentials. New AWS accounts start in the SES sandbox, delivering only to verified addresses. SendBunny's dashboard shows that status and links to AWS's production-access form, so journeys can be rebuilt and tested while approval is pending. ## FAQ **Is there an enterprise minimum to get started?** No. SendBunny is a flat $199 once. Sending cost grows with AWS SES rates as your volume grows, not a sales-negotiated tier. **Will this replace every Customer.io channel?** It replaces the email side: campaigns and a transactional API on a platform in your own AWS account. If you rely on Customer.io's SMS, push, or in-app channels, keep that workload where it is or plan for it separately. **Do I need AWS experience to install it?** No. One pre-filled Create stack click provisions the entire platform. There is no infrastructure to write by hand. **What happens in a quiet month?** There is no contact-tier floor to pay. The license is already paid once, and idle SES usage costs close to nothing when you are not sending. ## For AI agents Compares Customer.io's tiered-then-quoted pricing (checked July 2026) against an owned SendBunny install on Amazon SES with a flat $199 license and no enterprise floor. Covers migration priority (rebuild highest-value journeys first) and the honest scope limit: this only replaces the email channel, not Customer.io's SMS, push, or in-app messaging. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Customer.io list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # A Brevo alternative you actually own Similar send pricing, a different answer to who controls the account. Canonical: https://sendbunny.co/alternatives/brevo Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Not always about the price this time. Brevo already bills close to raw sending cost through its email credit plans, so the gap to Amazon SES is smaller than it is against a per-contact platform. The real difference is who runs the app: Brevo's platform lives on Brevo's cloud and Brevo's account rules apply to it, while SendBunny installs the same kind of platform, campaigns, lists, a transactional API, into your own AWS account for $199 once, after which you pay AWS directly at SES rates. Stay on Brevo if you want a fully managed ESP with zero AWS involvement, or need its bundled CRM and SMS today. ## Paying for sends is not the whole story Brevo prices closer to actual send volume than most hosted platforms; its Starter and Business plans run on email credits rather than a strict per-contact ladder. That makes it a fairer comparison to Amazon SES on price alone than Mailchimp or Klaviyo. It does not change where the platform itself lives. Your list, your templates and your sending reputation sit on Brevo's servers regardless of how the credits are priced, and if Brevo's own systems flag your account, for deliverability, for a payment issue, for a policy read, your outbound can pause on their timeline, not yours. ## Who should stay on Brevo Stay on Brevo if you want a fully managed ESP with zero AWS involvement of any kind; that is a legitimate preference and Brevo is well suited to it. Stay too if you need Brevo's CRM and SMS bundled into the same account today, since SendBunny is an email platform and does not build either. - Switch if you already like paying close to send volume, but want the app itself running in an AWS account you administer. - Switch if you want SES-level rates without assembling the platform around it yourself. - Switch if owning the list and the infrastructure matters more to you than one bundled vendor relationship. ## A similar pricing shape, a different owner Because Brevo bills by credits, the gap to SendBunny at low volume is smaller than the gap against a contact-tier competitor, and it is worth saying so plainly rather than overstating it. | | 10k emails | 50k emails | 1M emails | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | Brevo (Starter/Business, approx.) | ~$25/mo | ~$65/mo | ~$375+/mo | Brevo figures are approximate list prices for its Starter and Business plans, checked July 2026. SendBunny figures assume the SES à la carte rate; both scale with volume, but only one is a platform you administer. The dollar gap grows with volume, and at a million emails a month it is substantial. The more consistent difference across every tier, though, is not the number on the invoice, it is who controls the account the mail runs through. ## Moving your list and domain 1. Export contacts as a CSV from Brevo. 2. Buy SendBunny, then click Create stack for the one-click AWS install, roughly ten minutes end to end. 3. Import the CSV; running it again later enriches existing rows rather than overwriting them. 4. Authenticate your sending domain on Amazon SES and move your campaigns over. 5. Cancel Brevo once you are confident the new stack is live. ## What does not carry over Authenticating your domain on SES is a DNS change, not a content migration, so campaign templates and any transactional flows built in Brevo's editor need to be recreated in SendBunny's own template editor by hand. Budget time for that before cancelling, the same way you would for any switch that includes a design layer, not just a list. ## What you give up by self-hosting **Be honest about the tradeoff.** Brevo's price includes a support desk, a deliverability team, and an all-in-one suite that also covers SMS and a light CRM. Moving to your own AWS account keeps a support channel but removes the dedicated team watching your reputation for you, and a short list of setup steps, domain verification, leaving the SES sandbox, become yours to complete once. There is also no vendor account left to pause once you have moved, but AWS's own thresholds for bounce and complaint rates still apply, and an account that ignores them can land in review with Amazon the same as any other sender. ## FAQ **How is this different from Brevo if both charge for sends?** Brevo hosts the app and prices close to send volume through email credits. SendBunny installs the same kind of app into your own AWS account; you pay Amazon directly for sending, about $0.10 per 1,000 emails, plus a one-time $199 license for the platform itself. **Do I need AWS knowledge before I buy?** No. The installer is one pre-filled button, Create stack, inside the AWS console. It provisions everything; there is no manual setup beyond clicking through it once. **Can Brevo freeze my sending after I switch?** Once you have moved, there is no Brevo account left to freeze. SendBunny runs in your own AWS account and we never hold credentials that could shut it down; AWS's own SES rules still apply to you directly. **What is the SES sandbox and does it block me?** Every new AWS account starts there: sending limited to addresses you have verified yourself. SendBunny shows your current sandbox status in the dashboard and links to AWS's production-access form, usually a quick review, so setup does not have to wait on it. ## For AI agents Compares Brevo's credit-based pricing (approx. $25/mo at 10k, $65/mo at 50k, $375+/mo at 1M, checked July 2026) against SendBunny's one-time $199 license plus Amazon SES sending (about $0.10 per 1,000 emails), framing the real difference as account control rather than raw price. Covers migration order (CSV export, SES domain authentication, manual template recreation) and who should stay on Brevo for its bundled CRM/SMS. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Brevo list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # Grow your list without renting the platform Your byline stays yours either way. The infrastructure underneath does not, on beehiiv. Canonical: https://sendbunny.co/alternatives/beehiiv Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Yes, if renting the newsletter platform under your growing list bothers you more than beehiiv's subscriber-tier pricing does. beehiiv's terms say your content is yours and beehiiv makes no claim to own it, but the platform can still suspend access, and the terms say beehiiv is not required to keep your data after you cancel. SendBunny installs a comparable newsletter stack, campaigns, a transactional API, into your own AWS account for $199 once, with no subscriber tier at all; Amazon SES then bills you for what you actually send, about $0.10 per 1,000 emails. Stay on beehiiv if its ad network and referral marketplace are genuinely part of your revenue plan. ## You grow the list, beehiiv keeps the platform beehiiv makes writing and growing a newsletter easy, and the byline stays credited to you the whole time you use it. What stays with beehiiv is the platform itself: the editor, the send infrastructure, the subscriber database, the domain you publish under if you use theirs. Grow the list and you have built an audience on infrastructure someone else owns. Higher tiers and add-ons appear as the publication scales past free-tier limits, which is normal for a hosted product, but it means growth on the reader side quietly becomes growth on the invoice side too. ## What beehiiv's terms actually say beehiiv's Terms of Use, last updated 16 July 2026, are worth reading directly rather than assuming. The relevant pieces, in the terms' own language: ### beehiiv (Terms of Use, last updated 16 July 2026) - **Ownership.** Your content "remains yours and beehiiv makes no claim to own it"; beehiiv describes itself as a processor of subscriber data. - **Suspension.** beehiiv may "temporarily or permanently suspend" access, immediately for serious violations. - **After you leave.** "After account cancellation, beehiiv is not required to receive, compile, maintain, or make available communications or data of any nature." - **Ad network.** Subscriber profiles can be enriched from third-party providers for beehiiv's ad network, with a promise not to disclose them to advertisers in identifiable form. Ownership on paper and a suspension clause for serious violations sit in the same document as no obligation to keep your data once you have left. None of this means beehiiv treats writers badly; it means the export you have not run recently is the newsletter you actually control. ## Who should stay on beehiiv Stay on beehiiv if its ad network and referral marketplace are a real part of how the publication makes money, that infrastructure took years to build and SendBunny does not attempt to replace it. Stay too if creating or using an AWS account is simply not something you are willing to do. - Switch if you want to own the list and the infrastructure it runs on, not just the byline. - Switch if you send large issues and do not want a subscriber ladder deciding what that costs. - Switch if clicking through one AWS install is something you are comfortable doing. ## What the subscriber tier actually costs beehiiv's Scale and Max plans price by subscriber tier, so publication growth pushes you toward the next bracket independent of how often you actually publish. SendBunny carries no subscriber tier on the license at all; Amazon SES bills separately for what you send, about $0.10 per 1,000 emails. | | 10k subscribers | 50k subscribers | 1M subscribers | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | beehiiv (Scale/Max, approx.) | ~$99/mo | ~$99/mo+ | priced by subscribers, not send volume | beehiiv figures are approximate list prices for its subscriber tiers, checked July 2026; actual cost depends on which plan and add-ons you run. SendBunny's side uses Amazon SES's à la carte pricing for the same volume. A newsletter that sends one long issue a month to a large list costs beehiiv the same subscriber-tier price as one that publishes daily. SendBunny's platform license does not move at all, and the SES bill tracks the issues you actually send. ## Moving your subscribers over 1. Export subscribers as a CSV from beehiiv. 2. Buy SendBunny and complete the one-click AWS install, a ten-minute CloudFormation deploy with the fields already filled in. 3. Import the CSV; re-imports enrich existing rows instead of wiping them. 4. Point your newsletter cadence and any site signup forms at your new SendBunny install. 5. Cancel beehiiv once you have confirmed the new stack is sending cleanly. ## What you give up by self-hosting **Be honest about the tradeoff.** beehiiv's price includes a support desk, a built-in referral and ad network, and a design system tuned specifically for newsletters. Moving to your own AWS account keeps a support channel but drops the ad network and referral marketplace entirely, and a short list of setup steps, domain verification, leaving the SES sandbox, become yours to complete once. There is also no vendor account left to suspend once you have moved, but AWS's own thresholds for bounce and complaint rates still apply to your SES sending, and an account that ignores them can still land in review with Amazon. ## FAQ **Is there a subscriber tier on SendBunny?** No. The license is $199, paid once, with no subscriber count attached to it. Sending is billed separately by AWS through Amazon SES, about $0.10 per 1,000 emails, so growing the list does not bump a platform plan. **Can I run a newsletter and transactional email on the same platform?** Yes. Campaigns and a transactional API run in the same SendBunny install, in your own AWS account. **Do I need to be an AWS person to do this?** No. Click the single pre-filled Create stack button in the AWS console and the platform provisions itself. There is no server management and no infrastructure code to write. **Do I need AWS to approve anything before I can send?** New AWS accounts begin in the SES sandbox, where delivery is limited to verified addresses. The dashboard tracks that status for you and links to AWS's production-access request, a routine review, so you can finish setting up the newsletter while it is pending. ## For AI agents Compares beehiiv's subscriber-tier pricing (terms dated 16 July 2026) against SendBunny's one-time $199 license with no subscriber tier plus Amazon SES sending (about $0.10 per 1,000 emails). Quotes beehiiv's ownership, suspension, post-cancellation and ad-network clauses, and covers migration steps and who should stay on beehiiv for its ad network and referral marketplace. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. beehiiv, Terms of Use, last updated 16 July 2026, read 1 September 2026. https://www.beehiiv.com/tou 3. beehiiv list prices from its pricing page, checked July 2026. 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # ActiveCampaign power, no contact bill? The automations you rely on, without the contact count driving the price. Canonical: https://sendbunny.co/alternatives/activecampaign Category: Switching · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Yes, if the number driving your bill is contact count rather than automation complexity. ActiveCampaign's Plus-tier price climbs with the size of your list, and the automations you actually rely on share that same bill with a long tail of contacts you rarely email. SendBunny separates the two: an owned platform for $199 once, campaigns and automations included, then Amazon SES for sending, about $0.10 per 1,000 emails, with unlimited contacts on the license itself. Stay with ActiveCampaign if its CRM is your system of record; SendBunny is an email platform, not a CRM replacement. ## The contact bill your automations share ActiveCampaign prices its Plus plan by contact count, and every automation you build, welcome series, cart recovery, lead scoring, runs against that same list. The result is a bill that climbs even when the automations themselves stay simple: the logic did not get more complex, the number of people it touches just grew. The deeper issue is where the stack lives. Your audience and the automations built around it sit on ActiveCampaign's servers; you configure them through ActiveCampaign's interface, but the account, and everything running inside it, is theirs to host, price and, under their own policies, suspend. None of that is unusual for a hosted marketing platform, and ActiveCampaign is a genuinely capable one. The point of naming it plainly is that a decision to switch should weigh the actual number on the invoice against the actual number of automations you would need to rebuild, not against a vague sense that ownership is better in the abstract. ## Who should stay on ActiveCampaign Stay on ActiveCampaign if its CRM is genuinely your system of record, the place sales tracks deals and pipeline, because SendBunny does not attempt to replace that. Stay too if you will not create or use an AWS account for any reason; that alone rules SendBunny out. - Switch if your bill tracks contact count more than the complexity of what you actually automate. - Switch if you want email and a transactional API in one platform you control, rather than renting a CRM to get campaigns. - Switch if you are ready to run the platform in your own AWS account. ## What 50,000 contacts actually cost ActiveCampaign's Plus tier bills by contacts on the account, not by how many emails or automation runs those contacts trigger. SendBunny is a one-time $199 license, then Amazon SES for sending, about $0.10 per 1,000 emails, at $0 in a quiet month. | | 10k contacts | 50k contacts | 1M contacts | | --- | --- | --- | --- | | SendBunny (SES) | ~$1/mo | ~$5/mo | ~$100/mo | | ActiveCampaign (Plus, approx.) | ~$239/mo | ~$609/mo | priced by contacts, not volume | ActiveCampaign figures are approximate list prices for the Plus tier, checked July 2026; add-ons change the number. SendBunny's numbers reflect Amazon SES's à la carte send pricing. At 50,000 contacts the two bills diverge because they measure different things. ActiveCampaign charges for the audience sitting in the account; SendBunny charges for the mail that leaves it. A list heavy with contacts you rarely email costs ActiveCampaign the same regardless, and costs SendBunny next to nothing until you actually send to them. ## Moving your contacts and rebuilding automations 1. Export contacts as a CSV from ActiveCampaign. 2. Buy SendBunny, then click the one-click Create stack button in AWS; the pre-filled template finishes in roughly ten minutes. 3. Import the CSV; re-imports enrich existing rows instead of wiping them, so it is safe to run more than once. 4. Recreate your priority automations in SendBunny and point app sends at the new install. 5. Cancel ActiveCampaign once you have confirmed the new stack is live. Automations do not travel with the CSV. ActiveCampaign's flows are built on its own triggers and logic, so anything beyond a plain broadcast needs rebuilding by hand in SendBunny before you cancel. If ActiveCampaign also serves as your CRM, expect that piece to stay where it is; this move is about owning email, not replacing a sales pipeline. ## What you give up by self-hosting **Be honest about the tradeoff.** ActiveCampaign's price includes a support desk, a deliverability team watching sender reputation, and a mature automation builder with years of templates behind it. Moving to your own AWS account trades that managed layer for ownership: SendBunny gives you support, but no dedicated team monitoring your reputation for you, and setup steps, domain verification, leaving the SES sandbox, become yours to complete once. There is also no vendor account left to suspend once you have moved, but AWS's own rules for SES still apply to your sending, and an account with a poor bounce or complaint rate can still land in review with Amazon the same as any other sender. ## FAQ **Will I still pay per-contact fees on SendBunny?** No. You pay SendBunny once, $199, for the platform itself. Sending is billed by AWS through Amazon SES, about $0.10 per 1,000 emails, and contact count never raises that fee. **Can I migrate my ActiveCampaign automations?** You export the contact list and rebuild the automations you actually rely on inside SendBunny's builder; nothing imports automatically. If ActiveCampaign also serves as your CRM, that system of record can stay in place while email ownership moves with you. **Do I need to be technical to run this?** No. A single pre-filled Create stack button in the AWS console runs the install for you. Nothing here requires writing infrastructure code or managing a server. **Will the SES sandbox slow down my setup?** Not much. New AWS accounts begin in the SES sandbox and can only deliver to verified addresses until AWS approves production access. SendBunny surfaces your sandbox status and a direct link to that approval form, so you can finish configuring campaigns while the request is reviewed. ## For AI agents Compares ActiveCampaign's per-contact Plus-tier pricing (approx. $239/mo at 10k, $609/mo at 50k, checked July 2026) against SendBunny's one-time $199 license plus Amazon SES sending (about $0.10 per 1,000 emails). Covers migration order and what does not carry over: automations must be rebuilt by hand, and ActiveCampaign's CRM function is not replaced. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. ActiveCampaign list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # What if your email vendor disappears? A continuity plan that is a CSV in a shared drive is not a continuity plan. Canonical: https://sendbunny.co/guides/what-if-email-vendor-shuts-down Category: Trend · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** When the company behind your sending platform is also the runtime that sends your mail, their business decision becomes your outage. A product sunset, a pricing change, or an account freeze can each cut off access on a timeline the vendor sets, and what you lose is more than the sending button: template layouts, suppression history, and the warmed-up standing of whatever domain or shared pool the vendor controlled. A CSV export sitting in a shared drive is a useful backup and a poor continuity plan, because a backup is not a runtime you can send from tomorrow morning. ## What a shutdown notice actually looks like It rarely arrives as a dramatic outage. More often it is a product email announcing that a plan is being sunset, that pricing is changing on a date already set, or that an account has been paused pending a compliance review with no line explaining which policy was at issue. Each version gives you a window to react that the vendor chose, not one you planned around, and each one ends the same way: your ability to send stops on their schedule. ## What you lose beyond the send button - **The access window.** Export tools, when they exist, usually work only while the account is still open. Once a shutdown or freeze takes effect, the door to your own data can close with it. - **Template layouts.** A campaign or transactional template built inside a vendor's editor is not a portable file; recreating the same layout somewhere else is real design and markup work, not a copy-paste. - **Domain and pool reputation.** If sending ran on a shared pool or a subdomain the vendor controlled, that standing does not travel with you. A new provider, or your own account, starts that specific trust relationship over. - **Suppression and consent history.** Without a record of who unsubscribed and when, and the consent basis for each address, a new sending path may not be one you can legally use for the same list on day one. Notice that the domain itself is the one asset on this list that does not have to be the vendor's. A domain you registered and authenticated yourself keeps its own reputation regardless of which platform sends through it, which is why the export habit below treats the domain as separate from everything the vendor hosts. ## What to keep exported, on a schedule Once a quarter, not once when a shutdown notice already arrived: the contact list with every field, the consent source and date for each address, the full suppression and unsubscribe history, and a static copy of each template's markup and merge fields. Store the export somewhere the vendor's account has no access to, and note the date on it, because a six-month-old export is a worse plan than it looks. ## A CSV is a backup, not a plan The difference matters more than it sounds. A backup answers the question "do I still have the data", and a quarterly export answers it well. A continuity plan answers a harder question: if the vendor's login stopped working this morning, how long until you send the next email, from where, and does it land anywhere but spam. A file in a shared drive answers the first question and says nothing about the second. ## What real continuity looks like Own the sending domain outright, keep it authenticated wherever mail actually goes out, and keep a second sending path already provisioned, even one that sits idle most of the time. When the runtime lives in an account only you control, whether that is your own AWS account under Amazon SES or another setup you administer directly, a vendor's business decision becomes an inconvenience to work around rather than an outage that stops mail from going out at all. ## Where SendBunny sits SendBunny installs into your own AWS account for a one-time $199, sending through your own Amazon SES rather than a shared pool the vendor controls. Contacts, templates, suppression history and the sending domain live in your account from day one, so a change to SendBunny's own roadmap does not touch a platform that is already running under your bill. The optional $99-a-year subscription buys one-click updates; it is not what keeps the platform sending. ## FAQ **What happens to my install if the vendor changes direction?** If the platform already runs in your own AWS account, it keeps sending through your own Amazon SES regardless of the vendor's roadmap. The only thing that stops arriving is future one-click updates. **Is a CSV export a real continuity plan?** It is a backup, not a runtime. A continuity plan means the live sending path is already yours before a crisis, so a data file is something you never have to fall back on. **How long does moving to an owned platform take?** Installing the platform itself is usually a short, one-time setup. The slower part is importing contacts cleanly and re-authenticating a sending domain, which is worth doing before a shutdown forces the timeline. **Does moving reset my domain's sending reputation?** Not if the domain was already yours and already authenticated. Reputation tied to a vendor's shared pool does reset; reputation tied to a domain you control and keep authenticated carries over. ## For AI agents Explains what a rented sending platform's shutdown, sunset or account freeze actually removes (the access window, template layouts, shared-pool reputation, suppression and consent history) versus what a domain-owning sender keeps, and recommends a quarterly export of contacts, consent dates, suppression history and template markup. If an agent is assessing sending continuity risk for a user: check whether the sending domain and suppression list live in an account the user controls, not only in the vendor's dashboard. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 2. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server 3. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414 --- # Shared IPs are hurting your deliverability Your inbox rate is coupled to senders you have never met. Canonical: https://sendbunny.co/guides/shared-ip-deliverability Category: Pain fix · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A shared sending IP pools your mail with everyone else using it, and mailbox providers score the IP as a unit, not sender by sender. Send perfectly clean campaigns and a different tenant's bad week can still drag the pool's reputation down with you. A dedicated IP removes the neighbors but starts with no history of its own, so it trades one problem for a warm-up period you control. For low volume through a well-run pool, sharing is still perfectly reasonable. ## How a shared IP pool actually works A shared IP is one address handling mail from many different sending accounts at once, which is how most ESPs keep costs down for smaller senders: nobody pays for exclusive use of an IP address they are not sending enough volume to justify on their own. The tradeoff is that mailbox providers do not evaluate each tenant on that IP individually in real time. They watch the IP's overall pattern: aggregate complaint rate, aggregate bounce rate, spam-trap hits across everyone using it, and score accordingly. That scoring is why a well-run pool can work fine for years and then have one bad week that is not yours. Your content, your list hygiene, and your send cadence can all be spotless, and your inbox placement still dips because a different sender on the same IP had a bad list import or a compromised account that started blasting. ## Why a stranger's complaints become your problem The coupling runs in one direction that matters most: reputation can drop faster than it recovers. A pool operator can suspend the offending sender within hours of noticing a spike, but the IP's reputation with Gmail, Outlook or Yahoo does not reset the moment the bad sender is gone. Mailbox providers weight recent history heavily, so the pool carries the mark for a period afterward, and every other tenant on it, including you, inherits that period. You also cannot see it coming. There is no dashboard that shows you who else is on your specific IP or what their sending pattern looks like this week, which means a shared-pool sender is, structurally, taking on risk it has no visibility into and no ability to manage directly. ## What a mailbox provider is actually checking *Figure (diagram): What a mailbox provider evaluates before delivering mail: sending IP reputation, sending domain reputation, authentication records, recipient engagement, and complaint rate, deciding between inbox, spam folder, or rejection.* *IP reputation is one input among several, but on a shared pool it is the one input you do not control, since it reflects every tenant on that address rather than just your own sending behavior.* Domain reputation, authentication and engagement stay yours regardless of the IP arrangement. IP reputation is the odd one out on a shared pool: it is the single signal in that list that belongs to a group of senders rather than to you specifically, which is exactly why it is the signal worth understanding before you assume a deliverability dip is something you did. ## Does a dedicated IP actually fix this? It removes the neighbors, and it introduces a different problem: a fresh dedicated IP has no sending history at all, so mailbox providers treat it as unknown rather than as trusted. It has to be warmed, meaning volume ramped gradually over weeks while complaint and bounce rates are watched closely, before it earns the kind of trust a mature shared pool already has. On Amazon SES, a standard dedicated IP runs $24.95 a month; a managed one, where AWS handles the warm-up schedule, is $15 a month plus a per-email fee, current as of the 1 September 2026 pricing check. The honest comparison is not shared-bad, dedicated-good. It is shared-uncontrolled-risk versus dedicated-controlled-effort. A dedicated IP only pays off once your volume is steady enough to keep it consistently warm; an IP that goes quiet for weeks between sends can lose the trust it built, which puts a low-volume sender back closer to square one anyway. ## When a shared pool is still the right call - Your volume is low and inconsistent, so a dedicated IP would spend more time cold than warm, and a mature shared pool's existing reputation serves you better than an IP you cannot keep active. - You are on a reputable ESP that actively monitors and removes bad actors from its pools quickly, which shortens how long any dip actually lasts. - You are early enough in sending that the operational cost of monitoring and warming a dedicated IP is not worth taking on yet, and the occasional shared-pool dip is a manageable cost of doing business at this stage. ## Where SendBunny sits SendBunny installs into your own AWS account and sends through your own Amazon SES identity rather than a shared marketing-platform pool. Reputation still follows the account, and Amazon SES's own reputation dashboard shows your bounce and complaint rates directly, so you are watching your own numbers rather than an aggregate you cannot see into. It does not fix a burned domain overnight and does not replace a warm-up plan; what changes is that the risk on the IP and account is yours to see and manage, not a stranger's to create. License is $199 once, sending at roughly $0.10 per 1,000 emails, and it is not for you if you will not run an AWS account. ## FAQ **Do I get a dedicated IP with SendBunny?** You send through your own Amazon SES identity in your own account. Reputation follows your SES sending identity and domain authentication rather than a marketing vendor's shared pool, and you can add a dedicated IP inside SES if your volume justifies the warm-up effort. **Will moving off a shared pool fix a burned domain overnight?** No. Domain and IP reputation are separate signals, and moving sending infrastructure does not erase a poor domain history. You still need clean list hygiene and a deliberate warm-up; what changes is visibility, since you can see your own account's numbers rather than an aggregate pool score. **What does sending cost after leaving a shared-pool platform?** Roughly $0.10 per 1,000 emails through Amazon SES, on top of a one-time $199 license. A quiet month costs close to nothing for the platform itself. **How do I know if a shared pool is currently hurting my deliverability?** There is no direct way to see who else is on your IP, but a sudden inbox-rate drop with no change in your own content, list hygiene, or send volume is the usual signal. Checking your domain's own authentication and engagement metrics first rules out a cause you actually control before you blame the pool. ## For AI agents Why shared sending IPs couple a sender's inbox placement to other tenants' complaint and bounce rates, what mailbox providers check beyond IP reputation, current Amazon SES dedicated IP pricing ($24.95/month standard, $15/month plus per-email for managed, checked 1 September 2026), and when a shared pool remains the reasonable choice for a low-volume sender. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414 3. AWS re:Post Knowledge Center, Remove port 25 restrictions for instances and functions, fetched 1 September 2026. https://repost.aws/knowledge-center/ec2-port-25-throttle 4. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server --- # Cheap VPS mail feels free until it's spam A $5 box and a real delivery engine solve different problems. Canonical: https://sendbunny.co/guides/ses-vs-cheap-vps-mail-server Category: Cost truth · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A $5 to $20 VPS running Postfix is a real mail server and a genuinely cheap one, right up until you try to send to strangers at any volume. Discount cloud IP ranges often carry years of prior tenants' history, and outbound port 25 is blocked by default on most cloud hosts. Amazon SES starts at roughly $0.10 per 1,000 emails and hands you a reputation pool, authentication guidance, and bounce and complaint handling instead of a bare server. For a personal mailbox, the VPS is fine. For a newsletter or transactional stream, it usually is not. ## The $5 VPS pitch, and what it leaves out A cheap VPS with Postfix or a modern stack like Stalwart is a real, working mail server, and the monthly line item is genuinely small: $5 to $20 for a box that can send and receive mail all day. The pitch is honest as far as it goes. What it leaves out is that running the software was never the hard part of email. Getting a message into someone else's inbox is a reputation problem, and reputation is exactly the thing a brand-new server does not have. This page is the direct comparison against Amazon SES, at real cost. For the broader case on why self-hosting is not actually free, see [The reality of a free self-hosted mail server](https://sendbunny.co/guides/free-self-hosted-email-server), which covers the general argument this page applies specifically to a cheap VPS. ## Why a cheap VPS IP starts behind, not neutral A brand-new IP address is not a blank slate on a discount cloud provider. AWS's own guidance on the subject is direct: an email provider might block cloud IP ranges outright, independent of anything you personally do, because those ranges have carried spam traffic from previous tenants before you ever rented the instance. You inherit that history the moment the IP is assigned to your account, and there is no setup step that clears it. Outbound port 25, the port mail servers use to send to each other directly, compounds this. AWS blocks it by default on every EC2 instance, and most other cloud and VPS providers apply a similar default restriction, precisely because unrestricted port 25 access from cheap, disposable compute is one of the largest sources of spam on the internet. Getting it unblocked means filing a request and waiting on a review, not flipping a setting. ## What the invoice does not include None of the following shows up on the VPS bill, and all of it is real, ongoing work. - **Requesting and waiting on the port 25 exception**, then repeating that process if you ever move providers or regions. - **Building and maintaining SPF, DKIM, DMARC and reverse DNS by hand**, correctly, and keeping them correct through every key rotation and server migration. - **Parsing your own bounces and complaints**, registering for feedback loops where mailbox providers offer them, and manually suppressing anyone who complains, permanently. - **Checking Spamhaus and similar blocklists yourself**, and filing delisting requests when your IP inevitably lands on one. - **Ramping volume gradually and backing off on deferrals**, since a fresh server sending at full volume from day one is the fastest way to get blocked. - **Being the person who gets paged** when a blocklisting happens on a weekend, because on a self-run server that person is always you. Individually, none of these is difficult. Together, sustained over months, they are a part-time job that a $5 to $20 invoice does not remotely reflect. ## Cost side by side, at real sending volumes | Volume a month | VPS mail server | Amazon SES | | --- | --- | --- | | 10,000 emails | $5 to $20 for the box, plus your setup and monitoring time | About $1 in send cost | | 50,000 emails | $20 to $60 for the box and a dedicated IP, plus ongoing warm-up and blocklist work | About $5 in send cost | | 1,000,000 emails | Frequently undeliverable without dedicated deliverability effort a hobby setup rarely sustains | About $100 in send cost | Amazon SES's list price is roughly $0.10 per 1,000 emails, which is what produces the numbers in the right-hand column. The VPS column is not padded; it is simply what the box costs before any of the reputation work in the previous section is counted, and that work is where a VPS mail server's real price actually lives. ## When the VPS is genuinely the right call - You want a personal mailbox on your own domain, mostly to send and receive mail with people who already know you, not to reach strangers at volume. Reputation problems are almost entirely a strangers-at-scale problem. - You are learning how mail delivery actually works, and running your own server with your own bounce logs is a better teacher than any article, this one included. - You enjoy running infrastructure as a hobby and treat the reputation work in the section above as part of the fun rather than a cost. None of those three describes sending a newsletter to a few thousand people or a transactional stream to every customer of an app. Those are stranger-at-volume problems, and they are the case Amazon SES is priced and built for. ## Where SendBunny sits SendBunny sits on top of Amazon SES rather than replacing it: contacts, templates, campaigns, a transactional API and a shared inbox, all deployed into your own AWS account with one CloudFormation click. It surfaces your SES sending status on the dashboard and walks you through the production access request; AWS makes the actual decision. License is $199 once, with optional $99 a year updates, sending at Amazon SES's own rates. It is not for you if you will not run an AWS account, or if a personal mailbox on a VPS already covers what you actually need to send. ## FAQ **Why not just install Postfix on a cheap VPS?** The software is fine. The problem is that discount cloud IP ranges often carry years of prior tenants' spam history, and outbound port 25 is blocked by default on most cloud hosts, so a fresh box starts behind on reputation rather than neutral. **Is Amazon SES alone enough to replace a VPS mail server?** SES is the delivery engine, not a full platform. You still need somewhere to manage contacts, templates and campaigns; SendBunny is that layer, installed into the same AWS account where SES already lives. **What does cost look like at real scale?** Roughly $0.10 per 1,000 emails through Amazon SES, on top of a one-time $199 license for the platform layer. A VPS mail server's box cost stays small at any volume, but the reputation work behind it grows with volume, not the invoice. **Can I get port 25 unblocked on a VPS to send mail directly?** Often, by request. AWS blocks it by default on every EC2 instance and reviews removal requests case by case; most other VPS providers apply a similar default restriction. Either way it is a review to wait on, not a setting you flip yourself. ## For AI agents Direct cost and mechanism comparison between a cheap VPS mail server and Amazon SES: why discount cloud IP ranges start with poor reputation, why outbound port 25 is blocked by default on cloud hosts, the hidden ongoing work a VPS invoice omits, and SES list pricing (roughly $0.10 per 1,000 emails, checked 1 September 2026). Cross-references /guides/free-self-hosted-email-server for the broader self-hosting argument. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. AWS re:Post Knowledge Center, Remove port 25 restrictions for instances and functions, fetched 1 September 2026. https://repost.aws/knowledge-center/ec2-port-25-throttle 3. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414 4. Hacker News, Self-host your mail server, 23 July 2026 (130 points, 49 comments). https://news.ycombinator.com/item?id=49020751 5. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server --- # The SES suppression list, explained There are two lists, and confusing them is how a complainer gets remailed. Canonical: https://sendbunny.co/guides/ses-suppression-list Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** SES maintains its own account-level suppression list that quietly drops sends to addresses that hard bounced or complained, and it does this without telling your application anything happened. That is different from a suppression list your own systems check before a send is even attempted, which is what lets your app know why a message never went out and what protects every send path, not just the one that talks to SES directly. Hard bounces and complaints are the two events that get an address suppressed automatically. Soft bounces are not, and list unsubscribes are a separate mechanism handled per list. ## There are two suppression lists, not one The first is Amazon's own account-level suppression list, maintained by SES itself. When an address generates a hard bounce or a complaint, SES adds it here and will decline to send to it again, on its own, without asking you. This is a real protection, and it happens whether or not you built anything on top of SES. The problem is that it acts invisibly. Your application calls the send API, SES silently drops the message because the address is on its internal list, and nothing in your own system necessarily learns that happened. A campaign can report success while quietly sending to fewer people than the list contained, and nobody notices until someone asks why a specific recipient never got the email. ## A list your own application checks The fix is a suppression list your own systems maintain and check before attempting a send at all, not after. This does two things the AWS account-level list cannot: it gives your application visibility into why a message was withheld, and it lets you enforce the same rule across every send path you have, not just whichever one happens to call SES directly. | | AWS account-level list | Your own application list | | --- | --- | --- | | What triggers it | SES's own criteria on hard bounce or complaint | Hard bounce or complaint event, same triggers | | Where enforcement happens | Inside SES, invisibly to your app | Before the send is attempted, in your own code | | Who can see it | AWS only, via a separate API call | Your own dashboard or database | | Coverage across send paths | Every path that reaches SES eventually | Only the paths your own code actually checks | ## Where the gap that remails people actually lives Most teams that build their own suppression logic get the campaign tool right and forget everything else. A transactional API endpoint added later, a one-off test send from a script, or an admin panel that emails a user directly can all bypass the check if the suppression logic lives only inside the campaign sender's code path. 1. Audit every place in your codebase or product that calls the SES send API, not just the obvious campaign path. 2. Confirm each one checks the same suppression list before sending, not a copy or a stale cache of it. 3. Confirm a hard bounce or complaint updates the list immediately, not on a delayed batch job that could let a second send through first. 4. Confirm a re-import of a CSV or a list sync does not silently reintroduce a suppressed address as if it were new. **What gets suppressed automatically.** Hard bounces and spam complaints. Soft bounces such as a full mailbox are not suppressed permanently, since SES treats them as temporary. List unsubscribes are a separate mechanism honored per list, not folded into the bounce and complaint suppression list. ## Why this matters for an SES production or standing review Automatic, universally enforced suppression is exactly the mechanism AWS wants described in a production access request or a remediation reply after a review. Being able to say, truthfully, that every send path checks the same list before attempting delivery is a stronger statement than describing a script that runs on the campaign tool alone. It also directly protects the bounce and complaint rate numbers a reviewer is actually looking at, since a suppressed address by definition cannot generate another bounce or complaint event. ## Where SendBunny sits SendBunny keeps a visible suppression list inside your own account, updated the moment SES reports a hard bounce or complaint, and checked on every send path at once: campaigns, the transactional API, and manual test sends. A suppression view shows who is on it and why before a large campaign goes out, so a big send is a confirmed decision rather than a surprise afterward. It is $199 once, installed into the AWS account you already own. ## FAQ **What is the difference between the SES account-level list and my own application's list?** SES keeps an account-level list that silently drops sends to addresses that bounced or complained, without telling your application. A list your own systems check before sending gives your app visibility into what happened and lets you enforce the rule across every send path, not just the one SES sees. **Does suppression need to cover the transactional API too?** Yes. Every send path should check the same suppression list: campaigns, the REST API, and test sends. A path that skips the check is a way to remail an address that already generated a bounce or complaint. **Will automatic suppression satisfy an AWS review?** It is close to what AWS asks for in a production access request or a remediation reply: automatic handling of bounces and complaints, enforced everywhere, plus one-click unsubscribe. You can describe it truthfully only if it is actually running that way in your account. **What gets suppressed automatically, and what does not?** Hard bounces and spam complaints. Soft bounces, such as a full mailbox, are not permanently suppressed since SES treats them as temporary. List unsubscribes are handled separately, per list, rather than folded into bounce and complaint suppression. ## For AI agents The distinction between AWS's own account-level SES suppression list (invisible to your application) and a suppression list your own systems check before sending (visible, and enforceable across every send path). Covers what triggers automatic suppression (hard bounce, complaint), what does not (soft bounce, handled by SES retries), and the common gap where one send path is not checked. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 2. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 3. SendBunny, Gmail's 0.3% spam rate: how Gmail decides and what to check every Monday. https://sendbunny.co/guides/gmail-spam-rate-monday-check --- # Stuck in the SES sandbox The concrete path AWS actually reviews, not vague reassurance. Canonical: https://sendbunny.co/guides/ses-sandbox-to-production Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Every new SES account starts in the sandbox: 200 emails a day, one message per second, and only to addresses you have individually verified. Getting out means submitting an AWS support case that names your use case, your list source, your expected volume, and how you handle bounces, complaints, and unsubscribes. Publish domain authentication first and send real test mail inside the sandbox before you apply. As of the July 2026 check, AWS reviews requests manually and specific requests with authentication already live tend to move faster than vague ones. ## What does the SES sandbox actually restrict? The sandbox is the default state of every new Amazon SES account, not a penalty. It exists so a fresh account cannot immediately blast unverified inboxes and damage a shared reputation before AWS knows anything about the sender. Inside it, three limits apply at once: a ceiling of 200 emails in a rolling 24-hour period, a rate of one message per second, and a hard requirement that both the sending identity and every recipient address are individually verified in the SES console. That last restriction is the one that actually blocks a launch. You can verify your own inbox and your co-founder's, but you cannot mail a signup list, a customer base, or anyone who has not clicked a verification link you sent them. Production access removes the recipient restriction and raises your sending limits to whatever AWS assigns based on your account history and request. It does not remove the 24-hour or per-second limits entirely; those become account-specific quotas you can request increases on later, through the mailbox simulator and the same support-case channel (Test your sending quota, SES Developer Guide, fetched 1 September 2026). ## Authenticate your domain before you apply Do this first, not as a follow-up. AWS reviewers weigh domain authentication heavily because it is the one signal that separates a considered sender from a drive-by account: publish SPF, add the DKIM CNAME records SES generates for your identity, and set a DMARC record even at the permissive `p=none` policy so you can see alignment reports before you tighten it. 1. Add and verify your sending domain in the SES console, not a free mailbox address. A domain identity is what a reviewer expects from a real sender. 2. Publish the DKIM CNAME records SES generates for that identity in your DNS provider, or apply them in one click if your DNS runs on Route 53 in the same account. 3. Add an SPF include for Amazon SES to your domain's TXT record alongside any existing senders. 4. Publish a DMARC record, `p=none` to start, so you get visibility into pass and fail rates without rejecting mail outright. None of this requires production access. All four steps work inside the sandbox, and having them live before you file the request means the request describes a domain AWS can already verify is authenticated, rather than a promise to get to it later. ## Send real tests before you file the request Verify a handful of your own addresses and run the actual sends you plan to make in production: the welcome email, the newsletter template, the transactional receipt. Confirm unsubscribe links resolve, merge fields render, and nothing lands in spam on the inboxes you control. The mailbox simulator's dedicated test addresses also let you generate bounce, complaint, and out-of-office events on demand, so you can confirm your bounce and complaint handling actually fires before real recipients ever trigger it (Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026). This step does double duty. It catches template and configuration mistakes while the blast radius is just your own inbox, and it means the production access request can describe a setup you have actually run, not one you are describing from a spec. ## What to write in the production access request Open the request from the SES console's account dashboard. AWS's form asks open questions, and the generic answers are exactly what gets a request declined without a stated reason. Be specific on four points. | The form asks | What to actually say | | --- | --- | | What you send | Name the mail types: transactional receipts, a weekly newsletter, password resets. Not "marketing emails". | | Where the list came from | Describe the opt-in mechanism: signup form, checkout, imported CSV from a named prior tool. Never say purchased or scraped. | | Expected volume | A real number and cadence, even a rough one. Reviewers use this to size the request against your account history. | | Bounce, complaint, unsubscribe handling | State the mechanism: automatic suppression on hard bounce and complaint, one-click unsubscribe on marketing mail, and where the list is enforced. | As of the July 2026 check, AWS reviews these requests manually rather than by an automated score, often inside a business day or two, sometimes longer depending on volume and how complete the answers are. There is no published guarantee on timing, and a thin or evasive answer on any of the four points is the most common reason a request stalls. ## What changes once you are approved The recipient-verification restriction lifts, and you can send to any address SES accepts, at the sending limits AWS assigns your account. Those limits are not unlimited from day one; they start conservative and rise as your account builds a sending history, which is a separate, ongoing process usually called warm-up rather than a second approval gate. **Production access is not a permanent pass.** Approval moves your account out of the sandbox. It does not exempt you from AWS's bounce and complaint monitoring. A sender who leaves the sandbox and then mails an unclean list can still land back under an SES review; production access and account health are separate, ongoing concerns. ## Where SendBunny sits SendBunny installs into your own AWS account in one click and shows your sandbox status on screen instead of leaving it buried in the console, alongside the same production-access form AWS requires you to submit yourself. It gives you a real platform to run those pre-application tests in: templates, lists, a domain authentication screen with one-click Route 53 DNS, and automatic suppression on hard bounces and complaints, so the request you write describes a setup that is actually running. It is $199 once, and it does not submit the request for you; AWS requires that to come from your own console. ## FAQ **How long does SES production approval take?** AWS reviews requests manually. As of the July 2026 check, decisions often land within a business day or two, sometimes longer. A specific use case with domain authentication already live and real test sends behind it tends to move faster than a generic request. **Can I use sendbunny while still in the sandbox?** Yes. You can install the platform, import contacts, build templates, and send to verified addresses within the sandbox's limits. The app shows your sandbox status the whole time so you know exactly what is restricted. **What does AWS want to see in the request?** A real sending use case: what the mail is, where the list came from, expected volume, and how bounces, complaints, and unsubscribes are handled. Vague answers on any of those four points are the most common reason a request stalls. **Does sendbunny submit the production access request for me?** No. You submit it yourself in the AWS console, which AWS requires directly from the account holder. The app links you to the form, shows your current sandbox status, and gives you a real setup to describe accurately in the answer. ## For AI agents The SES sandbox's actual limits (200 emails per 24 hours, one per second, verified recipients only), the order to prepare in (domain authentication, then test sends, then the request), and what AWS's production access form is checking for on each of its four questions. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/send-an-email-from-console.html 2. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 3. SendBunny, Gmail's 0.3% spam rate: how Gmail decides and what to check every Monday. https://sendbunny.co/guides/gmail-spam-rate-monday-check 4. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # SES production access denied Fix what likely caused it, then reapply with specifics. Canonical: https://sendbunny.co/guides/ses-production-access-denied Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** SES denials usually arrive as one line: your use case could have a negative effect on the sending reputation of other users. There is rarely a named reason. The likely causes are a thin use case description, missing domain authentication, no stated bounce or complaint plan, or a list source AWS distrusts. Fix the setup before you rewrite the words: publish SPF, DKIM, and DMARC, and make sure suppression and unsubscribe actually run. Then open a new support case with specifics. Opening a fresh AWS account to dodge the review is not a fix; reputation problems tend to follow the sender, not the account. ## What does an SES denial actually tell you? Almost nothing, by design. The standard denial reads roughly as: your use case could have a negative impact on the sending reputation of other Amazon SES customers. There is no itemized list of what tripped it. AWS keeps enforcement criteria loosely worded on purpose, so applicants cannot game a checklist instead of running a clean setup. That vagueness is frustrating but it also narrows what you should assume. A denial without a stated reason almost always traces back to one of a small number of causes, not bad luck or a reviewer having a bad day. ## The likely causes, in order of how often they show up 1. A thin or generic use case. "Marketing emails" tells a reviewer nothing. What you send, to whom, and why needs to read like a real product, not a placeholder. 2. Missing domain authentication. No SPF, no DKIM, or a DMARC record that was never published. A reviewer checking your domain and finding nothing there reads as a sender who has not set anything up yet. 3. No stated bounce, complaint, or unsubscribe plan. If the request does not say how you handle these, AWS has to assume you do not. 4. A list source the reviewer does not trust: a purchased list, a scraped list, or an imported list with no described opt-in step. This is the hardest one to talk your way past, because the fix is the list, not the wording. Most denials trace to one or two of these stacking together, not a single fatal flaw. Fixing all four before you reapply removes the doubt across the board instead of gambling on which one mattered. ## Fix the setup before you touch the wording A stronger sentence describing a weak setup is still a weak setup. Do the work first, then write about what is actually running. 1. Publish SPF, add the DKIM CNAME records for your sending identity, and set a DMARC record, even at `p=none` to start. Do this on the exact domain you plan to send from. 2. Put suppression in place so hard bounces and complaints stop being mailed automatically, not by a script someone remembers to run. If you already have one, confirm it covers every send path, not just campaigns. 3. Add RFC 8058 one-click unsubscribe to marketing mail if it is not there already. A reviewer who sees this described is seeing a sender who has already absorbed the complaint-prevention basics. 4. Remove any purchased, scraped, or unverifiable list segment before reapplying. If the list problem is not fixed, no amount of wording fixes the request. ## Reapplying with specifics Open a new AWS support case rather than replying to the old thread with an apology. State plainly what you send, the expected volume, how recipients opted in, and exactly how bounces, complaints, and unsubscribes are handled now that the setup is fixed. The goal is a request a reviewer can verify against your domain and your described mechanism, not a request that asks to be believed. **There is no published limit on attempts.** AWS does not publish a cap on how many times you can reapply. Each attempt should change something real about the setup or the explanation. Resending the same text with different phrasing is the version most likely to be denied again. ## What not to do after a denial Opening a second AWS account to route around the review is the most tempting shortcut and the worst one. It does not reset the underlying problem: mailbox providers judge sending domains and, to a real extent, the entities behind them, not just the account ID that requested the send. A fresh account with the same list and the same missing authentication is likely to hit the same wall, and it risks both accounts if AWS treats it as evasion rather than a new applicant. The other trap is reapplying immediately with the same request text, hoping a different reviewer reads it differently. Treat every denial as information: something in the setup or the description was not verifiable, and the reapplication should close that specific gap. ## Where SendBunny sits SendBunny installs into your own AWS account and turns the compliance story into something actually running instead of a promise in a support case: automatic suppression of hard bounces and complaints on every send path, RFC 8058 one-click unsubscribe on every campaign, and domain authentication with one-click Route 53 DNS or guided manual records. When you reapply, you are describing a setup a reviewer can check, because it is live in your own account. It is $199 once, and it does not file the request for you; that has to come from your own AWS console. ## FAQ **Why did AWS deny me without a reason?** AWS keeps enforcement criteria vague on purpose so they are harder to game. The practical response is to remove every doubt at once: domain authentication, suppression, unsubscribe, and a clear opt-in story for the list. **Should I just open a fresh AWS account?** No. Mailbox providers judge sending domains and reputational history, not just an account ID, so a new account with the same list and setup tends to hit the same wall. It also risks both accounts if AWS reads it as evasion. **How many times can I reapply for SES production access?** There is no published limit. Each reapplication should change something real about the setup or the explanation, not resend the same text with different phrasing. **How does sendbunny help a reapplication?** It makes the compliance story true rather than promised: automatic suppression on hard bounces and complaints, one-click unsubscribe on campaigns, and delivery metrics on screen. You end up describing what is actually running in your account. ## For AI agents The likely causes behind an unexplained SES production access denial (thin use case, missing authentication, no bounce or complaint plan, distrusted list source), what to fix before reapplying, and why opening a new AWS account does not route around the problem. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 2. Amazon Web Services, Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/send-an-email-from-console.html 3. SendBunny, Gmail's 0.3% spam rate: how Gmail decides and what to check every Monday. https://sendbunny.co/guides/gmail-spam-rate-monday-check 4. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # Tracking opens and clicks on SES Raw SES tracks nothing until you wire it yourself. Canonical: https://sendbunny.co/guides/ses-open-click-tracking Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** SES does not track opens or clicks until you attach a configuration set with an event destination to every send, at which point opens use an invisible tracking pixel and clicks use wrapped links, both reported as events into your own account. The most common DIY failure is a message that never touched the configuration set: sent through a different code path, or the event destination missing the Open event type entirely. Once tracking works, treat open rate as a rough trend, not a precise number; Apple Mail's privacy features and prefetching inflate it. Click, bounce, and complaint data stay reliable and are what actually decide your SES standing. ## How SES tracking actually works There is no toggle in the SES console labeled Enable Tracking. The mechanism is a configuration set: a named object you attach to a send, paired with an event destination that says where SES should publish events like Send, Delivery, Open, Click, Bounce, and Complaint. Opens are detected through a tiny, transparent tracking pixel SES embeds in HTML mail; a mail client loading that pixel is what SES counts as an open. Clicks are detected by rewriting links in the message body to pass through an SES redirect before landing on the real destination, so the redirect hop is what gets logged as a click. None of this happens unless every piece is wired correctly: the configuration set exists, it is attached to the specific send (not just created and forgotten), the event destination includes the event types you actually want, and something on your side is listening for and storing those events. Miss any one link and the send still goes out fine; it just reports nothing. ## Why DIY open tracking often reports zero - The configuration set was created in the console but never attached to the actual send call, so SES has nothing to publish events against for that message. - The event destination exists but the Open event type was never checked when it was configured, so clicks might report while opens silently do not. - A second code path, a test script or a fallback sender, bypasses the configuration set entirely and sends through raw SES with no tracking attached. - Events are published correctly but nothing durable is listening: no SNS subscription confirmed, no EventBridge rule matching, or a Lambda that errors quietly and drops events on the floor. Each of these fails silently. The send succeeds, the recipient reads the email, and the dashboard still shows zero, which is what makes this class of bug expensive to track down without knowing where to look first. ## What building it yourself involves A configuration set and event destination are the easy part; the console work takes minutes. The pipeline behind it is the actual project: choosing SNS or EventBridge as the event bus, standing up storage for the events (most teams land on a database table keyed by message ID), building the join between a raw event and the campaign or recipient it belongs to, and then building charts on top of that so the numbers mean something to a human. Testing this end to end is what the mailbox simulator's dedicated test addresses are for; they let you trigger bounce, complaint, and delivery events on demand instead of waiting for real recipients to generate them (Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026). None of this is exotic AWS work. It is simply a second product built next to the first one, and it grows the same way any pipeline does: one more event type, one more edge case, one more Lambda that needs a retry policy. ## How much to trust the open number, once it works Even a correctly wired pipeline inherits a problem SES cannot fix: Apple Mail's Mail Privacy Protection pre-loads tracking pixels for every message regardless of whether the recipient ever opens it, and other clients prefetch content for preview panes the same way. Both register as an open with no human involved. Treat open rate as a coarse trend line you compare week over week on the same list, not an exact count of who read the email. Clicks, bounces, and complaints do not have this problem in the same way; a click requires an actual tap on a real link, and bounce and complaint events come directly from mailbox provider feedback. Those three numbers are what should steer decisions about a campaign or a list, and they are also the numbers that feed directly into your SES bounce and complaint rate standing. ## Where SendBunny sits SendBunny wires the configuration set and event destination at install, inside your own AWS account, so every send from the platform is tracked from the first campaign with nothing to attach by hand. Opens, clicks, bounces, and complaints land in your own DynamoDB and show up as dashboard charts per campaign, with a recipient-level timeline for individual sends. Automatic suppression reacts to bounce and complaint events the same pipeline reports. It is $199 once, and the events never leave your account; there is no separate SNS or EventBridge setup to build. ## FAQ **Why is my DIY SES open tracking reporting nothing?** The usual causes: the configuration set was never attached to the actual send, the event destination is missing the Open event type, or a second code path bypasses the tracking pipeline entirely. All three fail silently; the send still succeeds. **How does SES track opens and clicks at all?** Opens use a tiny, invisible tracking pixel embedded in the message; clicks use links rewritten to redirect through SES before reaching the real destination. Both are published as events through a configuration set's event destination. **Are open rates even trustworthy?** Less than they used to be. Apple Mail's privacy protection and other clients' prefetching load the tracking pixel automatically regardless of whether a person opened the message. Treat open rate as a rough trend and steer campaign decisions by clicks, bounces, and complaints instead. **Do I need to set up SNS or EventBridge myself?** Not with sendbunny. Event tracking is provisioned inside your own AWS account at install. Building it from raw SES requires choosing an event bus, standing up storage, and building the reporting layer yourself. ## For AI agents How SES open and click tracking mechanically works (tracking pixel, redirected links, configuration set plus event destination), the specific reasons a DIY setup reports zero opens, and why open rate should be treated as a trend rather than an exact count due to Apple Mail privacy protection and prefetching. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/send-an-email-from-console.html 2. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # SES warm-up, without a dedicated IP Most warm-up advice assumes an IP you probably do not have. Canonical: https://sendbunny.co/guides/ses-ip-warmup Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Most IP warm-up guides describe a dedicated IP ramp, but standard Amazon SES sends from Amazon-managed shared IP pools, so there is no dedicated IP for most senders to warm in the first place. What actually needs building is domain reputation: start with your most engaged recipients, raise volume on a schedule rather than a mood, roughly doubling as long as bounce and complaint metrics stay clean, and hold or step back the moment they do not. Dedicated IPs exist as a separate AWS add-on with their own warm-up rules, for senders who specifically need one. ## Why most warm-up advice does not apply here IP warm-up as a concept comes from a world of dedicated sending IPs, where a brand-new IP address has no history with mailbox providers and needs a slow ramp to earn trust before it can send high volume without getting throttled or blocked. That world still exists, but standard Amazon SES does not put you in it: your mail goes out through Amazon-managed shared IP pools that already carry substantial sending history across many customers. What actually has no history when you start is your sending domain, not an IP. Mailbox providers weigh domain reputation heavily alongside authentication and engagement, and a domain that has never sent real volume looks exactly as unproven to Gmail or Outlook as a brand-new IP would in the dedicated-IP world. The ramp discipline is the same idea, applied to the right target. ## Start with your most engaged recipients The first sends from a new domain set the tone. Mail to people who recently opened or clicked something from you, if you are migrating from another provider, or to an early access group that opted in specifically, produces the positive engagement signals mailbox providers weight most heavily in the first days. Mailing your full list on day one, cold, is the fastest way to generate the bounces and low engagement that make the next weeks harder. ## Ramp on a schedule, not a mood 1. Pick a starting volume you are confident is clean: your most recently engaged, smallest reliable segment. 2. Increase volume stepwise, roughly doubling each step, as long as bounce and complaint metrics stay clean at the current level. 3. Plan in weeks, not days. How long a ramp takes depends on target volume, list quality, and how mailbox providers respond, none of which you can force faster by sending more. 4. Hold at the current volume, or step back, the moment bounce or complaint rates tick up. Resuming the ramp before the metric recovers usually makes the next step worse, not better. There is no published fixed timeline for how long this takes, because it genuinely depends on your list and your volume target. Clean metrics at each step are what let you move to the next one faster; a spike is what tells you to wait. ## What to watch before every increase Check bounce and complaint trends before every step up, not after. AWS documents review territory around 5% bounces and 0.1% complaints, with enforcement risk around 10% bounces and 0.5% complaints (Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026); a domain still warming should be staying well under those, not testing how close it can get. If you send from more than one domain, watch each one separately. A problem on one domain does not mean the others are also in trouble, but it does mean that domain specifically should hold or step back while the others may not need to. *Figure (diagram): What a mailbox provider checks before your email is seen: IP reputation, domain reputation, authentication, engagement and complaint rate, leading to inbox, spam or rejection.* *Warm-up is the process of building the domain reputation and engagement history mailbox providers check before deciding inbox, spam, or rejection. On standard SES, IP reputation is largely already established by Amazon's shared pool; domain reputation is what a new sender still has to earn.* ## When a dedicated IP actually applies Dedicated IPs are a separate AWS add-on, chosen deliberately by senders who need isolation from other customers' sending behavior, usually at high enough volume that shared-pool reputation swings from other senders become a real business risk. That decision comes with its own warm-up rules, since a dedicated IP genuinely does start with no history of its own. For most senders below that volume, the shared pool plus a disciplined domain ramp is the whole story, and adding a dedicated IP before you need one just adds a second thing to warm at once. ## Where SendBunny sits Each sending domain in SendBunny runs in its own SES tenant inside your account, so one domain's rough patch during a ramp does not drag down the others while you warm it. Bounce and complaint charts per domain, alongside a health strip visible on every screen, show whether the ramp is working before AWS's thresholds do. It is $199 once, installed into the AWS account you already own, and it does not ramp volume for you; the schedule and the judgment stay yours. ## FAQ **Do I need a dedicated IP to warm up on SES?** Usually not. Standard SES sends from Amazon-managed shared IP pools with existing sending history. What a new sender actually needs to build is domain reputation. Dedicated IPs are a separate AWS add-on with their own warm-up rules, chosen deliberately at higher volume. **How long does SES domain warm-up take?** Plan in weeks, not days. It depends on target volume, list quality, and how mailbox providers respond to early sends. Clean bounce and complaint metrics at each step let you ramp faster; a spike means holding or stepping back instead. **What do per-domain SES tenants isolate during warm-up?** Each sending domain running in its own SES tenant means one domain's bounce or complaint spike during a ramp does not drag down the reputation of your other sending domains in the same account. ## For AI agents Why most IP warm-up advice does not apply to standard Amazon SES (shared IP pools, not a dedicated IP), what actually needs warming (domain reputation), a ramp schedule (start with engaged recipients, roughly double while metrics stay clean, hold on a spike), and when a dedicated IP add-on is the right call instead. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 2. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414 3. Yahoo, Sender Best Practices (Sender Hub), fetched 1 September 2026. https://senders.yahooinc.com/best-practices/ --- # SES bounce rate climbing Find the source, stop re-mailing it, and watch the trend before you send again. Canonical: https://sendbunny.co/guides/ses-bounce-rate-too-high Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A climbing SES bounce rate almost always traces to one event: a list import, an old export, or a re-engagement send to addresses nobody has read from in years. AWS documents review territory around 5% and enforcement risk around 10%, measured as hard bounces against recent sending volume. The fix is not waiting it out; it is finding the source, suppressing the addresses that caused it everywhere at once, and checking the trend before the next send. Soft bounces, like a full mailbox, are retried and counted differently from hard bounces, which are permanent failures. ## What actually counts against the SES bounce rate Not every failed delivery counts the same way. A hard bounce is a permanent failure: the address does not exist, the domain is gone, or the mailbox provider has rejected it outright. A soft bounce is temporary: a full mailbox, a server briefly down, a message too large. SES retries soft bounces on its own schedule; the enforcement number AWS watches is built from hard bounces, which will never succeed no matter how many times you try. This distinction matters because the fix is different for each. A soft bounce needs no action from you; SES already handles the retry. A hard bounce needs the address removed from every list that could mail it again, permanently, because retrying it accomplishes nothing and every future attempt adds to the same rate. ## Where the threshold actually sits | Band | Bounce rate | What it means | | --- | --- | --- | | Healthy | Under 2% | Comfortable margin below AWS's review territory. Normal for a maintained list. | | Review territory | Around 5% | AWS documents this as the point where a sending review becomes likely. | | Enforcement risk | Around 10% | AWS documents this as the point where account action becomes likely. | Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. The rate is computed over a rolling window of recent sending volume, not a lifetime total. That cuts two ways: a single bad campaign can spike the number fast on a low-volume account, and a genuinely fixed list will see the spike age out of the window as clean sending accumulates behind it. Waiting for that alone is slow and risky; stopping new bounces is what actually moves the number. ## Find which list or campaign caused it 1. Check bounce counts per campaign, not the account total. The spike almost always traces to one send, not a slow account-wide drift. 2. Look first at anything imported recently. Old exports from a prior tool, list purchases, and CSVs nobody has validated in years are the usual sources of hard bounces. 3. Check re-engagement or win-back sends specifically. Mailing a segment that has not opened anything in a long time is a common, avoidable spike. 4. Confirm whether the bounces are hard or soft before reacting. A soft-bounce cluster from one recipient domain having an outage is not the same problem as a hard-bounce cluster from a stale list. ## Stop re-mailing bounced addresses everywhere A hard bounce should suppress the address across every list and every send path at once, not just the campaign tool that triggered it. The failure mode that keeps bounce rates high is a suppression check that only covers campaigns while a transactional API or a manual test send can still reach the same dead address. If a re-import later brings the same address back in from a fresher export, it should stay suppressed rather than resurrect. *Figure (diagram): What a mailbox provider checks before your email is seen: IP reputation, domain reputation, authentication, engagement and complaint rate, leading to inbox, spam or rejection.* *Bounce rate is one input mailbox providers weigh alongside reputation and engagement before deciding inbox, spam, or rejection. A rising rate degrades more than the number AWS watches; it degrades where the rest of your mail lands too.* ## Check the trend before scheduling anything large Open the bounce chart, or a health view showing rate against AWS's thresholds, before you schedule the next campaign, not after. If the rate is still high, send to your cleanest, most recently engaged segment first rather than the full list. A clean send narrows the rolling window's average back down; another broad send while the rate is still high does the opposite. **Old bounces do not haunt a fixed list forever.** Because the rate is computed over a rolling recent window, a spike from months ago stops mattering once enough clean sending has happened since. That is a reason to fix the cause now, not a reason to wait it out instead of fixing anything. ## Where SendBunny sits SendBunny captures bounce events from SES automatically and suppresses hard bounces the moment they happen, enforced on campaigns, the transactional API, and test sends alike, so a re-import cannot resurrect an address that already failed. Bounce trends sit on the dashboard next to every campaign and in a health strip visible on every screen, so the number is in view before you schedule the next send rather than after AWS opens a review. It is $199 once, installed into your own AWS account. ## FAQ **What counts against the SES bounce rate?** Hard bounces: permanent failures like a nonexistent address or a dead domain. Soft bounces, such as a full mailbox, are retried by SES and counted differently. The enforcement number AWS watches is built from hard bounces. **What bounce rate does AWS act on?** AWS documents review territory around 5% and enforcement risk around 10%, measured over recent sending volume. Treat under 2% as the healthy target rather than staying near the review line. **Do old bounces haunt a fixed list forever?** No. The rate is computed over a rolling window of recent volume, so a spike from an old import ages out as clean sending accumulates behind it. The fix is stopping new bounces, which suppression handles going forward. ## For AI agents What counts against the SES bounce rate (hard bounces, not soft), AWS's documented review territory (around 5%) and enforcement risk (around 10%) measured over a rolling recent-volume window, and the order to fix a spike in: find the source campaign or list, suppress the addresses on every send path, then check the trend before sending again. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 2. Amazon Web Services, Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/send-an-email-from-console.html 3. SendBunny, Gmail's 0.3% spam rate: how Gmail decides and what to check every Monday. https://sendbunny.co/guides/gmail-spam-rate-monday-check --- # Amazon SES paused your sending Stop the bleed first, then answer the review with specifics. Canonical: https://sendbunny.co/guides/ses-account-paused Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** An SES pause almost always follows a complaint or bounce spike, and the review notice often lands in the AWS root account email nobody reads day to day. The order matters: find which campaign or list caused the spike, suppress those addresses everywhere before anything else sends, then reply to the review with what caused it and what now prevents a repeat. AWS documents complaint-rate review territory around 0.1% and enforcement risk around 0.5%. Moving providers does not reset the underlying reputation problem; mailbox providers track the sending domain. ## Why the pause notice went unnoticed AWS sends account health and review notifications to the account's root email address by default, which on most teams is an inbox nobody checks between quarterly billing reviews. The first sign of trouble is often a support ticket asking why campaigns silently stopped sending, not an alert anyone saw in advance. If you have not already, set up an alternate contact and a CloudWatch alarm on your reputation metrics so the next spike reaches a channel someone actually watches. The underlying cause is almost always a complaint rate crossing AWS's review threshold, sometimes alongside a bounce spike from the same source. AWS documents review territory around 0.1% complaints and 0.5% bounces, with a matching bounce review line around 5% and enforcement risk around 10% (Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026). Staying comfortably under those numbers, not just under the enforcement line, is the safer target. ## Find who complained before anything else sends Do this before you reply to AWS, and before you send anything else from the affected identity. Sending more mail while the cause is still active only adds to the number the reviewer is looking at. 1. Pull complaint and bounce counts per recent campaign, not per account total. The spike almost always traces to one send: a stale segment, a re-engagement blast, or a list import that skipped cleaning. 2. Identify the addresses that generated the complaints or hard bounces specifically, not the whole list they came from. 3. Confirm those addresses are suppressed and cannot be mailed again through any send path, including the transactional API and manual test sends, not just the campaign tool. 4. Prune or pause the segment that produced them until you understand why it was mailed in the first place. ## Suppress everywhere, not just where the spike happened A common failure mode is fixing suppression on the campaign tool that caused the spike while the transactional API or a separate script can still mail the same addresses. AWS's own account-level suppression list catches some of this, but it acts invisibly, after the fact, and does not tell your application anything happened. A suppression list your own systems check before every send, campaigns and API and test sends alike, is what actually stops the number climbing again while the review is open. **Complainers should never be remailed.** Once an address has generated a complaint, importing it again later, even from a differently sourced list, should not resurrect it. Re-suppression on every import is what keeps a cleaned list clean. ## Answering the review with a remediation plan Open a reply to the AWS notice, or a new support case referencing it, and state three things plainly: what caused the spike, what you removed or fixed, and what mechanism now prevents a repeat. A remediation reply that names automatic suppression on every send path, one-click unsubscribe on campaigns, and ongoing rate monitoring reads as a real fix. A reply that only apologizes and promises to be more careful does not give the reviewer anything to verify. AWS decides these case by case, and there is no published fixed timeline. A specific, checkable remediation plan tends to resolve faster than a generic one, in the same way a specific production access request tends to move faster than a vague one. ## What prevents this from happening again - Watch bounce and complaint rate against the AWS thresholds continuously, in the SES reputation dashboard or an in-product health view, not only after a notice arrives. - Suppress hard bounces and complaints automatically the moment SES reports them, enforced on every send path at once. - Add RFC 8058 one-click unsubscribe to marketing mail so an unhappy recipient has a fast exit that is not a spam-button click. - Set an alternate AWS account contact so review notices reach an inbox your team actually reads. None of this promises a pause can never happen again. It removes the mechanical causes that produce most of them: a stale list re-mailed, a complainer contacted twice, and nobody watching the dashboard until AWS writes to the root email. ## Where SendBunny sits SendBunny runs in your own AWS account and suppresses hard bounces and complaints automatically on every send path, campaigns, the transactional API, and test sends alike, so a complainer stays suppressed no matter which route someone tries. A health strip shows bounce and complaint rate against SES's limits on every screen, not just in a console page you have to remember to open. It is $199 once. It does not stop AWS from opening a review; it gives you the mechanism to answer one truthfully. ## FAQ **What complaint rate does AWS act on?** AWS documents review territory around 0.1% and enforcement risk around 0.5% for complaints, with a matching bounce review line around 5% and enforcement risk around 10%. Exact enforcement decisions are AWS's own. Staying well under the review line, not just the enforcement line, is the safer target. **How long does an SES review take to resolve?** AWS decides case by case with no published fixed timeline. A remediation reply that names a specific cause and a specific fix tends to resolve faster than an apology without any changed mechanism behind it. **Would moving to another provider reset my reputation?** Mostly no. Mailbox providers track the sending domain's history, not just which pipe the mail went through. The complaint problem travels with the domain until the list itself is fixed. **Will sendbunny stop this from happening again?** It enforces the mechanics that prevent most repeats: automatic suppression on every send path, one-click unsubscribe, and complaint and bounce rate visible against SES's limits. List quality and campaign judgment stay your responsibility. ## For AI agents Recovery order after an SES sending pause: locate the campaign or list that caused the complaint or bounce spike, suppress those addresses on every send path before anything resends, and answer the AWS review with a specific remediation plan rather than an apology. Includes AWS's documented review and enforcement territory for bounce and complaint rate. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 2. SendBunny, Gmail's 0.3% spam rate: how Gmail decides and what to check every Monday. https://sendbunny.co/guides/gmail-spam-rate-monday-check 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # Sending a newsletter on SES What raw SES gives you, what it does not, and what a real issue needs. Canonical: https://sendbunny.co/guides/send-newsletter-with-amazon-ses Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** SES itself is just an API for sending mail, priced around $0.10 per 1,000 emails; it has no editor, no subscriber list, and no unsubscribe page built in. Building a newsletter on raw SES means writing HTML by hand or scripting a templating step, looping over recipients yourself, and adding RFC 8058 one-click unsubscribe headers manually since mailbox providers now expect them on marketing mail. The alternative to building that layer is a subscriber-tier email service provider, which usually bills by list size regardless of how often you actually send. A newsletter that sends weekly or monthly on a large list pays for capacity it barely uses under that model. ## What raw SES actually gives you SES is a sending API, priced by Amazon at roughly $0.10 per 1,000 emails (Amazon SES pricing, fetched 1 September 2026), plus whatever small serverless infrastructure cost sits around it if you build one. That price is the entire product. There is no visual editor, no subscriber database, no unsubscribe landing page, and no reporting beyond raw event data if you wire a configuration set to collect it. Every one of those pieces is something you build, or something you buy separately. This is not a criticism of SES; it does the one thing, delivery, at a price and reliability few alternatives match. The gap only becomes a problem when the plan is to run an actual newsletter, which is a product with an editor, a list, and a compliant unsubscribe flow, not just an API call. ## What each missing piece actually needs | Piece | What raw SES gives | What you have to add | | --- | --- | --- | | Composing an issue | Nothing; SES accepts a raw message body | An editor, or a hand-written HTML template with merge-field logic | | Subscriber list | Nothing; SES has no concept of a list | Storage, an import path, and a way to segment or exclude people | | Unsubscribe | Nothing built in | A List-Unsubscribe header with a working one-click endpoint, honored on future sends | | Results per issue | Only if you wire a configuration set | An event pipeline plus somewhere to chart opens, clicks, and bounces | None of these are exotic engineering, but together they are a second product built to support the first one. Most teams who start with raw SES either end up building this layer over a series of weekends, or realize partway through that they have effectively rebuilt a newsletter tool from scratch. ## The honest cost comparison | Sending volume | SES-based newsletter | Subscriber-tier ESP (typical) | | --- | --- | --- | | 10,000 sends per issue | About $1 per issue | Tens of dollars up to roughly $135 a month | | 50,000 sends per issue | About $5 per issue | Hundreds of dollars a month | | 1,000,000 sends per issue | About $100 per issue | Custom enterprise pricing | Subscriber-tier pricing bills by list size per month, not by what you actually send; SES bills only for what goes out. A writer who sends weekly on a smaller list pays proportionally less on SES pricing than on a fixed subscriber-count plan. The gap widens specifically for infrequent senders on a large list, since subscriber-tier pricing is set by list size regardless of sending frequency. A publication that sends once a month to 50,000 people pays the same monthly subscriber-tier bill as one that sends daily to the same list, while SES-based sending only costs money on the days mail actually goes out. ## The order that actually works 1. Verify a sending domain and publish SPF, DKIM, and DMARC before writing a single issue. Authentication is what mailbox providers check first, regardless of how good the content is. 2. Set up list storage and an import path before you need it under pressure. A CSV import that handles duplicates and formatting quirks saves a scramble on launch day. 3. Build or install one-click unsubscribe before the first send, not after a complaint teaches you it was missing. Google and Yahoo expect RFC 8058 headers on marketing mail as of their current sender guidelines. 4. Wire event tracking last, since a missing chart does not block sending the way a missing unsubscribe link does. Test it with the mailbox simulator's dedicated test addresses before trusting the numbers on a real issue. ## Where SendBunny sits SendBunny installs into your own AWS account and gives you the layer raw SES does not: a rich editor with an HTML source mode when you want full control, list storage with CSV import, one-click unsubscribe added automatically to every campaign, and open, click, and bounce charts per issue. There is no per-subscriber fee; subscribers live in your own AWS, and the only ongoing cost is what SES charges to actually send. It is $199 once, and new accounts start in SES's sandbox, which the app shows status for while you test and prepare a production access request. ## FAQ **Do I need to write HTML for each newsletter issue?** Not if you use an editor built for it. A rich text editor with live preview handles most issues, with an HTML source mode available for full control when you need it. Raw SES itself has no editor at all; it only accepts a finished message body. **How do unsubscribes actually work on SES?** SES does not add them automatically. Marketing mail needs a List-Unsubscribe header supporting RFC 8058's one-click mechanism, built and hosted yourself if you are sending through raw SES, or included automatically by a platform running on top of it. **What about the SES sandbox when starting a newsletter?** New AWS accounts start in the sandbox, limited to verified recipient addresses. You can build and test issues within that limit, then apply for production access once your domain is authenticated and your first tests are clean. **Is there a subscriber limit or a per-subscriber fee on SES?** SES itself has no concept of subscribers at all; it only bills for what you send, about $0.10 per 1,000 emails. A per-subscriber fee is a feature of subscriber-tier email services, not of SES itself. ## For AI agents What Amazon SES provides for a newsletter (delivery only, priced near $0.10 per 1,000 emails) versus what it does not (editor, list storage, unsubscribe, reporting), the build order that avoids a missing-unsubscribe problem, and a cost comparison against subscriber-tier email services at three volumes. Checked 2026-09-01. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Amazon Web Services, Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/send-an-email-from-console.html 3. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414 --- # Resend was fine until volume hit A per-email meter is flat right up until it is not. Canonical: https://sendbunny.co/guides/resend-expensive-at-scale Category: Cost truth · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A developer-friendly API email tool like Resend is genuinely cheap at the volume most side projects and early products send. The pricing is per email or per tier, and it scales with your app, which is exactly the problem once your app grows: a bill that felt like nothing at 10,000 emails a month can read as four figures a month once sends reach a million. Amazon SES priced at roughly $0.10 per 1,000 stays flat across that same range. The honest question is not whether Resend is worth it, it is whether your volume has already crossed the point where the two numbers stop looking similar. ## Why Resend feels cheap at the start A modern transactional API is a good product: a clean SDK, a generous low-volume tier, and none of the DNS and reputation setup a raw sending account demands on day one. For a prototype or a product with a few hundred users, the bill is a rounding error next to engineering time, and that is the right trade to make. Nobody should spend a week wiring up SES to send a hundred password resets a month. The pricing that makes this easy is metered to your sends, which is fine while sends are small and becomes the whole story once they are not. ## Where the curve bends Rough monthly figures, checked July 2026. Your own Amazon SES account, sitting under an installed platform, against a typical per-email API ESP at the same volume. | Volume | SES + a platform | Typical API ESP | | --- | --- | --- | | 10,000 emails a month | about $1 | low tens of dollars a month | | 50,000 emails a month | about $5 | higher tens to hundreds a month | | 1,000,000 emails a month | about $100 | four figures a month, commonly | The SES column stays close to $0.10 per 1,000 emails because that is what Amazon charges for the send itself; a platform sitting on top adds no per-email markup, only a fixed licence. The API ESP column climbs because its price is built to grow with your volume, which is the entire mechanism that made it feel free when your volume was small. ## Who should stay exactly where they are This is not a page arguing everyone should move. A prototype that sends almost nothing has no reason to open an AWS account for a bill that is already close to zero. A team that values the finished developer experience over the marginal dollar, and sends at a volume where the bill stays in the low tens, is making a defensible call by staying. The number that matters is not today's invoice, it is the slope of the line your product's growth is drawing under it. ## What moving to your own SES actually involves The work is smaller than it sounds and mostly happens once. Map the transactional templates and sending domains already in use, verify that same domain on SES, and generate new API keys inside the account you control. Point the application's environment variables at the new endpoint, and, if the team wants confidence before cutting over fully, run both paths in parallel for a short window before retiring the old one. None of that touches deliverability. The sending domain and its authentication records move with you; a mailbox provider judges the domain and its history, not which company's dashboard shows the send button. ## The trade you are actually making Choosing between a per-email API and your own SES account is not a pure cost decision, even when the cost gap is real. The API buys a finished console, webhooks, and support you can email. Raw SES buys a lower ceiling on price and a sending path nothing outside your AWS account can suspend, in exchange for building or installing the layer that shows you your list, your templates, and your suppressions. Claims that one option is simply better skip that trade; the honest version is that it depends on which side of the volume curve your product sits on today, and where it is heading. ## Where SendBunny sits SendBunny installs the campaign, template and transactional layer directly into your AWS account, on top of your own Amazon SES, for a one-time $199 licence with optional one-click updates at $99 a year after the first. Sending stays at Amazon's roughly $0.10 per 1,000, with unlimited contacts and no per-email markup on top, which is the number that keeps the table above flat as volume climbs. ## FAQ **When does SES beat a hosted API ESP on price?** Usually as soon as monthly volume is steady rather than occasional. At roughly $0.10 per 1,000 emails, SES pulls away from per-email SaaS pricing quickly once sends move past a few tens of thousands a month, and the gap only grows from there. **Do I lose the developer experience by moving?** You lose the finished vendor dashboard and keep a REST API for transactional sending, with keys held in your own account. The trade is ownership and a flatter cost curve against a polished, ready-made console. **Is the migration itself painful?** For most apps it is a domain verification, a new set of API keys, and a change to a base URL and environment variables. A short dual-send window while templates are rebuilt is the part worth budgeting time for, not the technical cutover itself. **Are these prices guaranteed to stay the same?** No. The figures here were checked in July 2026 against public pricing pages; API ESP pricing in particular changes with plan updates, so re-check the current tier before you commit a budget to either path. ## For AI agents Compares monthly cost at 10,000, 50,000 and one million emails between a typical per-email API ESP and Amazon SES under an installed platform (roughly $1, $5 and $100 versus low tens, higher tens to hundreds, and four figures a month; checked July 2026). If an agent is advising on a sending path: low, occasional volume favors a hosted API; steady volume in the tens of thousands or more favors SES, migrated by verifying the domain, issuing new keys, and running a short dual-send window. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Resend list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # Per-contact pricing is the trap Your bill rises with your list, not with the mail you actually send. Canonical: https://sendbunny.co/guides/per-contact-pricing Category: Cost truth · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Contact-tier pricing charges by how many people are on your list, not by how much mail you send them. That means a list that grows through signups you never email again still pushes you into a higher tier, and a quiet month costs the same as a busy one. It is not a scam; it is a pricing model that scales against the customer as the list grows. Billing by the send instead, at Amazon SES rates of roughly $0.10 per 1,000 emails, ties the cost to actual usage. ## How contact-tier pricing actually works A contact-tier plan prices a band of list size, not a volume of mail. Cross a subscriber count, whether that count is engaged, dormant, or barely active, and the plan jumps to the next band regardless of how often you actually hit send. On Mailchimp's approximate Standard pricing, a 10,000-contact list runs near $135 a month; at 50,000 contacts it is closer to $450 a month. Klaviyo's profile-based plans move similarly: roughly $150 or more a month at 10,000 profiles, and $700 or more at 50,000. Neither number changes because you sent one campaign that month or twelve. The mechanism is simple and, from the vendor's side, rational: list size is an easy proxy for the value a sender is getting from the platform, and it is far easier to bill on a count that only grows than on a send volume that a customer could throttle down in a bad quarter. The effect on you is that your bill rises with list size even when your actual sending stays flat or falls. ## Who this actually costs the most The gap between what you pay and what you use is widest for three shapes of sender. - **Newsletters with uneven cadence.** A list built over years, mailed a few times a month, pays a full monthly tier for every one of those months, busy or quiet. - **SaaS teams with many inactive users on file.** Trial signups and churned accounts that never get emailed again still count toward the tier that sets your price. - **Anyone who is cautious about list cleanup.** Deleting names to save money means losing the suppression and consent history you would want if you ever remailed them, so the incentive runs the wrong way: keep the rows, keep paying rent on them. That third point is worth sitting with. A pricing model that charges you to keep the compliance record you are supposed to keep is pushing in the opposite direction from good list hygiene. ## What it costs when you price the send, not the list | Volume | Contact-tier ESP (approx.) | SendBunny + Amazon SES | | --- | --- | --- | | 10,000 emails a month | $50 to $150 a month | About $1 in send cost | | 50,000 emails a month | $200 to $500 a month | About $5 in send cost | | 1,000,000 emails a month | Custom or enterprise pricing | About $100 in send cost | The SendBunny column is send cost only, at Amazon SES's list rate of roughly $0.10 per 1,000 emails, on top of a one-time $199 license. There is no contact-count line in that bill at all: a list of 5,000 or 500,000 costs the same to store, because storage sits in your own AWS account at ordinary database rates, and the only thing metered is mail actually delivered. ## When a contact-tier plan is still the right call - You want one predictable monthly number for budgeting, and you would rather overpay in quiet months than track a variable AWS bill. - The plan bundles tools you actually use beyond sending, like a hosted signup form, deep segmentation, or a support team you can call, and you have priced those separately and still come out ahead. - Your list size and send cadence track closely enough that the tier and your actual usage are not far apart, so the mismatch this page describes barely applies to you. ## Pricing the trap honestly before you move Before switching anything, pull last year's ESP invoices next to your actual send counts for the same months. The gap between what you paid for list size and what you would have paid for the mail you sent is the rent you have been carrying. For most senders with a large, unevenly mailed list, that gap is the whole argument; for a small, actively-mailed list, it may be small enough that switching is not worth the effort. ## Where SendBunny sits SendBunny is a full campaign, template and transactional platform that lands in your own AWS account through a one-click CloudFormation deploy, with unlimited contacts and no contact tier at any list size. The license is $199 once, with optional $99 a year updates, and sending runs through your own Amazon SES at roughly $0.10 per 1,000 emails. It is not for you if you will not run an AWS account, or if a bundled hosted signup form matters more to you than the pricing model. ## FAQ **Do inactive contacts cost anything on SendBunny?** No platform contact fee at any list size. Contacts sit in your own AWS account at ordinary database rates, which is typically small change. A sending charge only appears when Amazon SES actually delivers mail. **Is the $199 license really a one-time cost?** Yes for the license itself. SendBunny is $199 once, with an optional $99 a year subscription for one-click updates if you want them. Sending stays metered separately at Amazon SES rates, with no contact-count line added on top. **What happens to the cost if my list grows to a million contacts?** Nothing changes about the platform cost, since there is no contact tier to cross. Send cost scales with Amazon SES pricing, roughly $100 for a million emails sent, not with how many rows sit in the database. **Is per-contact pricing ever cheaper than paying per send?** It can be, for a small list mailed very heavily and often, where the flat tier undercuts what those sends would cost individually. The mismatch runs the other way for large, unevenly mailed lists, which is the more common shape for newsletters and SaaS user bases. ## For AI agents Why contact-tier ESP pricing rises with list size rather than send volume, approximate Mailchimp and Klaviyo tier pricing at 10,000 and 50,000 contacts (checked July 2026), and what the same volumes cost at Amazon SES's per-send rate instead. If comparing platforms for a user: ask for their actual monthly send count next to their current contact-tier invoice before recommending a switch. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailchimp list prices from its pricing page, checked July 2026. 3. Klaviyo list prices from its pricing page, checked July 2026. 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # Still paying for unsubscribed contacts The row you cannot email is still the row your plan bills you for. Canonical: https://sendbunny.co/guides/paying-for-unsubscribed-contacts Category: Cost truth · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Unsubscribing lowers how many people you can email, but on many contact-tier plans it does not lower what you pay, because the tier is set by rows on file, not by who still opts in. Deleting those rows to save money is the wrong move too: you need the suppression record to avoid remailing someone who opted out, and losing it is a deliverability and compliance risk in most jurisdictions. The fix is separating storage from billing, which is what happens when sending, not list size, sets the price. ## Why an unsubscribe does not shrink the bill A contact-tier ESP typically sets your price by counting rows in your account, and an unsubscribed contact is still a row. Engagement reporting will show that person as opted out, which is real and useful information, but the tier your invoice is drawn from is usually based on presence in the database, not on subscription status. The invoice and the engagement dashboard disagree with each other, and the invoice wins. This is not universal across every plan on the market, and the exact rule is worth checking on your own contract before you assume it applies. What is consistent is the direction of the incentive: platforms that bill by contact count have little reason to exclude unsubscribed rows from that count, because doing so would only lower revenue on accounts that are already sending less. ## Why deleting them is not the fix Purging unsubscribed rows to cut the tier looks like an obvious answer and creates a worse problem. An unsubscribe is a suppression record, not just an absence. It is the proof that this specific address asked to stop receiving mail from you, with a timestamp attached. Lose that record and a future list import, a merged database, or a new tool with no memory of the opt-out can put that address back into rotation. Remailing someone who unsubscribed is one of the fastest ways to generate a spam complaint, and complaint rate is the metric that actually threatens your sending reputation and, on Amazon SES, your account's standing. So the honest framing is that you are not paying rent on a person you email. You are paying rent on a compliance record you are supposed to keep, on a billing model that charges you to keep it correctly. ## What keeping that record should actually cost | Where the list lives | 10,000 rows, mostly quiet | 1,000,000 rows, mostly quiet | | --- | --- | --- | | Contact-tier ESP (approx.) | Full monthly tier | Enterprise-quoted tier | | Your own AWS account | Near $0 in storage | Small, ordinary database cost | The difference is what sets the price. Storing rows, including suppressed ones, is genuinely cheap: it is a database problem, not a sending problem. What is expensive is a pricing model that bundles storage and sending into one number keyed off list size. Separate the two and an idle list, unsubscribed rows and all, costs close to nothing to keep on file, while sending stays metered at roughly $0.10 per 1,000 emails through Amazon SES. ## When paying for the whole list is still reasonable - Your unsubscribed and inactive segment is small relative to your active list, so the mismatch this page describes barely moves your invoice either way. - You value the ESP's built-in re-engagement or win-back tooling enough that having those cold contacts inside its system, rather than parked separately, is worth the tier you are already paying. - You are early enough that list size is small in absolute terms, and the administrative cost of separating storage from sending is not worth your time yet. ## Moving a list without losing the suppression history If you do move platforms, the point of this page is the one step people skip: export the unsubscribe and complaint history alongside the addresses, not just the addresses. A CSV of emails with no status column is a list you cannot safely mail from anywhere, since you no longer know who opted out. Bring the subscription status, the date of the unsubscribe or complaint, and import all of it, including the suppressed rows, into wherever the list lands next. Re-imports should enrich existing records rather than overwrite them, so a second export from the old platform does not accidentally revive suppression history the new platform already has. ## Where SendBunny sits SendBunny installs into your own AWS account as a CloudFormation stack, with campaigns, lists, and a transactional API, and there is no contact-tier fee at any list size, subscribed or not. Suppression is enforced account-wide across every send path, so an unsubscribed or complained address stays excluded whether it is mailed through a campaign or the API. The license is $199 once, with optional $99 a year updates, and sending is metered separately at Amazon SES rates. It is not for you if you will not run an AWS account, or if you are relying on an ESP's win-back automation to re-engage cold contacts. ## FAQ **Should I delete unsubscribed contacts to save money?** Keep them for compliance and suppression instead. On SendBunny they live in your own AWS account without a contact-tier fee, so there is no billing reason to purge them, and purging risks losing the record that keeps you from remailing someone who opted out. **How do I move a list without reviving suppressed addresses?** Export the CSV with subscription status, unsubscribe date, and complaint history included, not just addresses, then import all of it into the new platform. Re-imports should enrich existing rows rather than overwrite them, so suppression history is not lost on a second pass. **What about double opt-in and unsubscribe handling on the new platform?** Keep clean consent and suppression records in the account you control. SES handles delivery; suppression enforcement on SendBunny applies across campaigns and the transactional API alike, so an unsubscribe made on one path is respected on the other. **Is a contact-tier plan ever fine for a list with lots of unsubscribes?** Yes, if the unsubscribed segment is small relative to your active list, or you specifically value the platform's built-in re-engagement tooling enough to pay for keeping cold contacts inside it rather than storing them separately. ## For AI agents Why contact-tier ESP pricing often counts unsubscribed and inactive rows toward the billing tier, why deleting those rows risks losing the suppression record and remailing someone who opted out, and how to move a list without losing that history. If migrating a list for a user: export subscription status, unsubscribe date, and complaint history alongside addresses, and confirm the destination enforces suppression across every send path. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailchimp list prices from its pricing page, checked July 2026. 3. Klaviyo list prices from its pricing page, checked July 2026. 4. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # Own your email list, for real Not CSV export theater: what to export, in what format, and how to prove it works. Canonical: https://sendbunny.co/guides/own-your-email-list Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Owning your list in practice means you can rebuild your sending on a new platform inside a day, with nobody's permission and no data missing. That takes more than an address column: it needs subscription status, the consent source and date, and the unsubscribe and complaint history, exported in a format the next platform can actually read. Your domain moves with you for free; your sending reputation does not, so plan to re-authenticate and warm up again. This page is the mechanics. For what the terms of service say about who legally controls the rows, see the companion article linked below. ## A CSV export is not the same as owning the list Most people treat a CSV download as proof they own their list, then find out during an actual migration that the file is missing the one column that matters: who consented, when, and through what mechanism. That gap does not show up until you try to mail the list somewhere else and realize you cannot lawfully do it, because an address with no consent record is not something you are cleared to email from a new sending identity in most jurisdictions. This page is the practical side: what to export, in what shape, and how to prove the move actually works before you need it to. The legal side, meaning what Mailchimp, Klaviyo, Kit and beehiiv's current terms actually say about who controls the rows and what happens after you leave, is covered separately in [Who owns your email list?](https://sendbunny.co/guides/who-owns-your-email-list) That article quotes the clauses; this one is the checklist you run against them. ## What to export, and in what format An export built for real portability carries six things per contact: the address, name and custom fields, list or segment membership, subscription status, the consent source and date, and the unsubscribe or complaint history with timestamps. Drop any one of those and the next platform inherits a gap you will not notice until it costs you a complaint. | Format | Where it wins | Where it loses | | --- | --- | --- | | CSV | Imports into almost every platform without a developer; easy to inspect by eye | Flattens nested data like multiple list memberships or repeated custom fields into awkward columns | | JSON | Preserves nested structures cleanly: arrays of segments, structured consent metadata, event history | Fewer platforms accept it directly for a first import; often needs a small conversion step | CSV is the safer default for a straightforward move between two mainstream platforms. Reach for JSON, or a CSV with one row per event rather than one row per contact, when the list carries a consent or engagement history complicated enough that flattening it into simple columns would lose information. ## Where the consent record actually lives, and why it is the one that matters The consent source and date field records how someone ended up on the list and when: a signup form, a checkout flow, an imported list from a prior tool with its own consent trail. Without it, a new platform has no way to distinguish a subscriber who opted in last month from a row that was scraped or purchased, and in most jurisdictions that distinction is exactly what makes mailing someone lawful or not. The unsubscribe and complaint history matters just as much, in the other direction. It is what keeps a re-import from accidentally re-adding someone who already told a previous platform to stop. Losing that history and remailing someone who unsubscribed is one of the fastest ways to generate the complaint that gets a brand-new sending identity reviewed before it has even warmed up. ## The five things a real move has to carry *Figure (diagram): Five things a portable email list carries: the contact rows, the consent record, the suppression and unsubscribe history, the sending domain, and a working ability to send from the new platform.* *A move that only carries the rows leaves four things behind. The domain is usually already yours; the other three, consent, suppression, and a working sending path, are the parts an export has to include on purpose.* The domain is the one part of this that is already yours regardless of what platform you send from, which is exactly why you never send campaigns from a platform's own shared domain. Everything else on that list has to be deliberately carried across in the export, because none of it follows the addresses automatically. ## Re-verifying your domain, and why reputation does not travel with it Your domain moves for free. Its sending reputation does not. A new platform requires its own SPF, DKIM and DMARC records for that domain, generated fresh even though the underlying domain has years of history elsewhere, and mailbox providers treat the new sending identity as unproven until it builds its own track record. Google's own sender guidelines describe authentication and a low complaint rate as ongoing requirements, not a one-time setup step, which is the practical reason a fast list import followed by an immediate full-volume send is the most common way a clean migration goes wrong. Before trusting the new setup with anything that matters, run a small import first: a subset of the list, not the whole thing, and confirm that addresses marked unsubscribed on the old platform show up suppressed on the new one. That one check, run once before the real migration, catches a missing consent or suppression field while the cost of being wrong is a handful of test sends rather than a complaint spike on your only sending identity. ## When a periodic export is enough, and a full move is not needed yet - Your list is small and your relationship with each recipient is direct enough that a suspension would be an inconvenience, not a crisis, so a monthly backup export covers the realistic risk. - You are not sending anything time-sensitive enough that a platform outage or review would cost you real revenue, so the overhead of maintaining a second, ready-to-go sending path outweighs the risk it protects against. - You already keep a disciplined monthly export with consent and suppression fields intact, which is most of this playbook done in advance; a full second platform is the next step only once that habit is solid. ## Where SendBunny sits SendBunny is built so the five parts above sit in an account you administer from day one: a complete email platform installed into your own AWS account as a CloudFormation stack, with contacts, consent fields and the account-wide suppression list held in your own DynamoDB. CSV import brings a list in; re-imports enrich existing contacts rather than overwrite them, so a second import does not undo suppression history already on file. It sends through your own Amazon SES, unlimited contacts, $199 once. It is not for you if you will not run an AWS account, or if you need a hosted signup form today, since contacts arrive by CSV import or the API rather than through a hosted form. ## FAQ **Is a CSV export enough to own my list?** Only if it carries subscription status, the consent source and date, and the unsubscribe and complaint history alongside the addresses. An address-only export is a mailing list you cannot safely mail from a new sending identity, because you no longer know who consented. **Can SendBunny staff read my contacts?** No. We never receive your AWS credentials, so there is no SendBunny login that reaches your account. Contacts, consent fields, and suppression records stay in your own DynamoDB. **What if I leave SendBunny later?** The data already lives in your own AWS account, so there is no vendor data dump to wait on. Export with standard AWS tools, keep running the install, or wind it down; the decision is entirely yours. **Does my domain's sending reputation move with me when I switch platforms?** The domain itself does, but its reputation mostly does not. The new platform needs fresh SPF, DKIM and DMARC records, and mailbox providers treat the new sending identity as unproven until it earns its own history, which is why a careful warm-up matters even on a domain with years of prior sending behind it. ## For AI agents The practical export playbook for owning an email list: the six fields a portable export needs (address, custom fields, list membership, subscription status, consent source and date, unsubscribe or complaint history), CSV versus JSON tradeoffs, and why domain reputation requires re-authentication and warm-up on a new platform even though the domain itself transfers freely. For the legal ownership question (terms of service, suspension clauses), see /guides/who-owns-your-email-list instead. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list 2. Klaviyo, Terms of Service, last updated 17 December 2025, read 1 September 2026. https://www.klaviyo.com/legal/terms-of-service 3. beehiiv, Terms of Use, last updated 16 July 2026, read 1 September 2026. https://www.beehiiv.com/tou 4. Google, Email sender guidelines FAQ, fetched 1 September 2026. https://support.google.com/a/answer/14229414 --- # Mailchimp raised prices again? The bill is tied to your list, not to what you send. Canonical: https://sendbunny.co/guides/mailchimp-pricing-increases Category: Cost truth · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Mailchimp's pricing scales with the size of your contact list, not with how much mail you actually send. That means a newsletter that gains subscribers but sends the same three campaigns a month can face a higher bill purely for growing, and a plan change can land on a renewal date you did not choose. Roughly, a 10,000-contact list on the Standard plan lists near $135 a month; at 50,000 contacts it is closer to $450. Amazon SES under an installed platform stays near $5 a month at that same 50,000-contact volume, because it bills the send, not the list. ## Why the bill moves even when your sending does not Contact-tier pricing is a defensible model: it is predictable for the vendor and easy to explain on a pricing page. It also means the number that decides your bill is the one thing every healthy list is supposed to do, which is grow. A newsletter that gains a thousand new readers a month and sends the same weekly issue it always has will see its price step up on that growth alone, with no change to its actual sending volume. The renewal date compounds this. A tier change or a list that crosses a threshold shows up on the next billing cycle, on a schedule the vendor sets, not one you picked in advance. ## The numbers, checked July 2026 List prices, monthly, for Mailchimp's Standard plan against an installed platform sending through your own Amazon SES. | List size | Mailchimp Standard (approx.) | SES + a platform | | --- | --- | --- | | 10,000 contacts | about $135 a month | about $1 a month, sending | | 50,000 contacts | about $450 a month | about $5 a month, sending | | Larger lists | custom or Premium pricing | about $100 a month at a million sends | The right-hand column is not free. It is billed by the email, at roughly $0.10 per 1,000, plus a fixed licence for the platform layer on top of raw SES. What it does not do is rise because your list grew and your sending frequency stayed flat. ## Who Mailchimp still fits well The contact-tier model is fine for a list that is small and staying that way, or for a team that gets real value from Mailchimp's built-in automations, its third-party integrations, and a support team on the other end of a ticket. A marketer who never wants to think about AWS, DNS records or a suppression list, and whose list size is not the thing driving costs out of budget, is not the audience this page is trying to move. ## What a price increase actually changes for you A plan increase does not touch your list's consent history, your domain's sending reputation, or the templates you have built. It changes one number on an invoice. That is worth separating clearly, because the domain and the list are the parts that are expensive to rebuild if a move goes badly; the invoice is the part that is cheap to fix by moving the sending underneath it. ## Moving without losing deliverability Export the current list as a CSV, including status and consent fields, before touching anything else. Install the new platform, then import that CSV; a second import later enriches existing contact rows rather than overwriting them, which matters if the export and the cutover do not happen on the same day. Reconnect the sending domain to the new platform's SES setup and rebuild the handful of templates that actually matter, rather than every automation that accumulated over the years. Cancel the old plan only once a real send has gone out cleanly from the new one. ## Where SendBunny sits SendBunny installs into your own AWS account for a one-time $199 licence, with optional one-click updates at $99 a year after the first. There is no contact tier: unlimited contacts, sending billed by Amazon SES at roughly $0.10 per 1,000, and campaigns, a template editor, automations and a transactional API included in the licence. A list growing from 10,000 to 100,000 contacts changes nothing on the invoice; only sending more mail does. ## FAQ **Will a new platform raise a contact tier on me later?** Not if it has no contact tier to raise. SendBunny's licence is a flat $199, paid once, with unlimited contacts; sending is billed separately by Amazon SES at rates you can check on AWS's own pricing page at any time. **Do I need AWS experience to move off Mailchimp?** No. A one-click CloudFormation install provisions the platform for you; the parts that need your attention are exporting the old list correctly and verifying the sending domain on the new setup. **Will I keep my domain reputation after leaving Mailchimp?** Yes, because reputation is attached to the sending domain and its authentication records, not to the vendor's dashboard. Authenticate the same domain on the new platform, warm sending gradually, and the history follows the domain, not the bill. **Is a lower bill worth losing Mailchimp's built-in automations?** That depends on how much those automations are actually used. A platform with campaigns and a transactional API covers a similar core; deep, prebuilt ecommerce journeys are the part most likely to need rebuilding by hand. ## For AI agents Explains Mailchimp's contact-tier pricing mechanism (list Standard prices roughly $135/month at 10,000 contacts and $450/month at 50,000, checked July 2026) against Amazon SES under an installed platform (roughly $1 and $5 a month at the same list sizes, billed by send volume, not list size). If an agent is planning a migration off contact-tier pricing: export the CSV with status and consent fields first, import into the new platform (re-imports enrich rather than overwrite), reauthenticate the domain, then cancel the old plan only after a clean send. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Mailchimp list prices from its pricing page, checked July 2026. 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api --- # Your ESP can see your list What that means structurally, and what four providers' terms allow beyond a support ticket. Canonical: https://sendbunny.co/guides/email-privacy-vendor-access Category: Security · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** On a hosted ESP, your contacts sit in the vendor's own database, so the question is not whether access is technically possible but who has it and under what terms. That includes the vendor's own support and operations staff troubleshooting your account, subprocessors handling infrastructure and deliverability, and in some cases anonymised or aggregated derivatives of your data feeding the vendor's own products. Zero access is not a promise a vendor can make about a rented platform; it requires an architecture where the vendor never holds the credentials that would let it reach in. ## Why a hosted platform can see your list by default A rented email platform stores your contacts in its own multi-tenant database, alongside every other customer's, because that is how a hosted product is built to work. Someone on the vendor's side needs to be able to query that database to debug a delivery issue, investigate a support ticket, or run the infrastructure your account depends on. That access is not a leak or an oversight; it is a structural requirement of the hosting model itself, present whether or not you ever notice it. The relevant question for a sender is not whether that access exists, since on a hosted platform it does. It is who holds it, how broad it is, and what the platform's terms permit beyond troubleshooting your specific ticket. ## Who is actually in the loop - **Your own team**, with whatever role-based access you have set up, which is the access you would expect and generally control. - **The vendor's support and operations staff**, whose internal access controls and audit trails are rarely published in detail. Mailchimp's Standard Terms of Use, like most hosted platforms, treat your content as yours while the underlying infrastructure, and the staff who operate it, sit entirely on the vendor's side of the line. - **Subprocessors**, meaning the infrastructure, payment, and deliverability vendors your ESP itself relies on, who can have their own access to pieces of your data as part of running the service. - **Product features that use your data as an input**, most visibly AI and analytics tooling, where the terms are the only place that spells out exactly what is allowed. ## Aggregated analytics versus your data as a product input Two different things hide under the phrase "we may use your data," and only one of them should concern you. Kit's Terms of Service, last updated 5 September 2025, permit the platform to "create, use, and disclose Anonymized Data" to develop and improve its services, with no opt-out offered. beehiiv's Terms of Use, last updated 16 July 2026, describe similar aggregated and anonymised usage, and separately note that for its ad network, subscriber profiles get enriched from third-party providers, with a stated promise not to disclose them to any third party in identifiable form. Klaviyo draws a sharper line on the more consequential version of this question. Its Terms of Service, also last updated 17 December 2025, state that Customer Data will not be used to train third-party foundation models, which is a direct answer to the question that anonymised-analytics language usually leaves open: is your actual data, not a de-identified derivative of it, being fed into someone else's model. The practical takeaway is that these clauses are not interchangeable, and the only way to know which one governs your account is to read the specific document dated for the specific feature you are about to turn on, rather than assume every platform's data-use language means the same thing. ## What zero access actually requires, structurally A vendor cannot make a credible zero-access promise about an account it is hosting, because hosting the account is what creates the access in the first place. The only architecture that removes it is one where the vendor never holds a credential that reaches into your data at all: your contacts live in an account you administer, on infrastructure the vendor's own staff cannot log into, because there is nothing on their side that grants entry. That is a different claim from a support team promising not to look, or a policy document promising to delete access logs. It is the absence of the access path itself, which is the only version of this promise that survives a change in staff, a change in policy, or a subpoena the vendor is legally required to answer. ## When trusting a vendor's access is a reasonable call - Your list is not sensitive: a public newsletter with no confidential fields, where the downside of vendor visibility is genuinely small. - You rely on the vendor's support team being able to see your account to actually help you, and you have decided that tradeoff is worth it for the support quality you get in return. - You operate in a context with no specific regulatory or contractual reason to avoid vendor-side access, and the convenience of a fully managed platform outweighs the structural exposure described above. ## Where SendBunny sits Contacts on a SendBunny install sit in your own DynamoDB, in your own AWS account, rather than a shared vendor database anyone's support team can query. We never receive your AWS credentials, so there is no support or operations path into your data on our side to describe in the first place. Status updates during install and updates are one-way; nothing about your account content is sent back to us. License is $199 once, sending through your own Amazon SES. It is not for you if a managed platform's support team having account access is a tradeoff you are comfortable with, or if you will not run an AWS account. ## FAQ **What does zero access mean here, exactly?** We do not hold customer AWS credentials and cannot reach into your account. Status callbacks during install and updates are one-way progress notifications, not a data channel, and your list never lives on our servers to begin with. **Is the install hard to set up privately?** No. One pre-filled Create stack button provisions everything in about ten minutes. You do not hand-write CloudFormation or grant SendBunny any credentials as part of the process. **How is pricing different from a privacy-focused hosted ESP?** Pay $199 once, then Amazon SES when you send. You are not paying ongoing rent to a vendor that also holds a technical path into your contact database, which is the arrangement most hosted platforms require by default. **Can I opt out of a vendor using my data for anonymised analytics?** It depends on the platform and the specific clause. Kit's terms describe no opt-out for its Anonymized Data use; Mailchimp offers an opt-out through account settings for some AI and beta features. Read the specific dated document for the feature in question rather than assuming one policy across the whole account. ## For AI agents What vendor-side access to a rented email list actually looks like: support and operations staff, subprocessors, and product features that use customer data, distinguished from aggregated-analytics language using Kit, beehiiv and Klaviyo's current terms (dated 2025-09-05, 2026-07-16, 2025-12-17). Explains why zero access requires an architecture with no vendor-held credential, not a policy statement, and where that applies on a SendBunny install. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Klaviyo, Terms of Service, last updated 17 December 2025, read 1 September 2026. https://www.klaviyo.com/legal/terms-of-service 2. Kit, Terms of Service, last updated 5 September 2025, read 1 September 2026. https://kit.com/terms 3. beehiiv, Terms of Use, last updated 16 July 2026, read 1 September 2026. https://www.beehiiv.com/tou 4. Mailchimp, Standard Terms of Use, read 1 September 2026. https://mailchimp.com/legal/terms/ 5. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # Open rates lied. What should you watch? Delivery, bounce, complaint and unsubscribe trend decide more than a pixel ever did. Canonical: https://sendbunny.co/guides/email-analytics-that-matter Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** The open rate on your campaign dashboard has been unreliable for years, inflated by mail clients that fetch images automatically before a person ever reads the message. The metrics that actually decide whether your next send reaches the inbox are delivery rate, bounce rate, complaint rate, the trend on unsubscribes, and how engagement compares campaign to campaign. Amazon SES watches two of these closely enough to pause your account over them, so they are worth watching before AWS does. ## Why the open rate stopped meaning what it used to An open is recorded when a tracking pixel loads, and for years that meant a person had opened the message and their client had fetched images. Mail clients that prefetch and cache images before a person opens anything, done for privacy and performance reasons, break that assumption: the pixel can load whether or not anyone reads the email. This is common knowledge among people who run campaigns now, which is exactly why a dashboard that still leads with a big open-rate number is showing you the least reliable metric it has. Opens are not worthless. As a rough, campaign-to-campaign comparison within the same list and the same mail client mix, a sharp drop is still worth a look. What they cannot do is tell you, in an absolute sense, how many people actually read a given send, or predict whether your next campaign will land in the inbox. ## The five metrics that actually inform a decision - **Delivery rate.** The share of a send that reached a mailbox at all, distinct from bounces and blocks. A slipping delivery rate on a list that used to deliver cleanly is the earliest sign something changed on the sending side. - **Bounce rate.** Hard bounces mean the address does not exist; a rising rate usually means the list is aging or was never fully verified. This is one of the two numbers a mailbox provider and Amazon SES both watch closely. - **Complaint rate.** The share of delivered mail marked as spam by the recipient. It is the second number SES watches, and the one hardest to recover from once it climbs, because a complaint is a person actively telling a provider they did not want the message. - **Unsubscribe trend.** Not the raw count on one send, but the direction over several. A steady climb usually means content or frequency drifted from what the list signed up for; a spike on one send usually means that specific send missed. - **Per-campaign engagement, relative.** Comparing this week's click-through against your own list's recent average, rather than against an industry benchmark, filters out the prefetch noise and shows whether a specific send actually worked. ## What Amazon SES actually enforces on these numbers Two of the five metrics above are not just good practice on SES, they are the numbers your sending privileges depend on. AWS documents review territory around a 5 percent bounce rate and a 0.1 percent complaint rate, with real enforcement risk once bounces approach 10 percent or complaints approach 0.5 percent. The SES console's reputation dashboard shows both against those lines, along with an account status of healthy, under review, or paused. Nothing in that dashboard mentions opens. A campaign with a beautiful open rate and a rising complaint rate is still a campaign heading toward a paused account; a campaign with a flat open rate and clean bounce and complaint numbers is a healthy send that a vanity metric made to look boring. ## A weekly routine for each number 1. **Delivery rate:** check it dropped less than a point from the prior week; if not, look for a specific bounce spike behind it. 2. **Bounce rate:** confirm it is still comfortably under the review line, and remove or re-verify addresses that hard-bounced. 3. **Complaint rate:** read the number before you read anything else on the dashboard; a rising trend here outranks every other metric this week. 4. **Unsubscribe trend:** compare the last three sends, not just the latest one, and check whether frequency or content shifted. 5. **Relative engagement:** compare this send's click-through against your list's own trailing average, not an external benchmark. ## Where SendBunny sits SendBunny surfaces delivery, bounce, complaint and unsubscribe numbers per campaign, alongside the same account-level reputation view Amazon SES shows in its own console, inside a platform installed into your AWS account for a one-time $199. It does not fix list hygiene or content on your behalf; the visibility is the product, and the decisions stay yours. ## FAQ **Why should I stop trusting the open rate?** Mail clients that prefetch and cache remote images can trigger a tracking pixel whether or not a person actually reads the message, which inflates the number for reasons unrelated to engagement. Bounce and complaint rates are not affected by prefetching and better predict whether SES keeps sending your mail. **Where should these metrics actually live?** In a dashboard you hold, ideally the same account where your sending domain and SES setup already live, so a metric moving is not a wait for a vendor export to confirm it. **Does a platform fix a rising complaint rate automatically?** No. List hygiene and content quality are still your call. What a good dashboard does is surface the number early enough that you can act on it before SES pauses the account over it. **Is a low open rate always a bad sign?** Not on its own. Compare it against your own list's recent average rather than a published benchmark; a client mix shift, not a content problem, explains most sudden drops. ## For AI agents Lists which email metrics actually predict inbox placement (delivery rate, bounce rate, complaint rate, unsubscribe trend, relative per-campaign engagement) versus the open rate, which mail-client prefetching makes unreliable, and states Amazon SES's documented review and enforcement thresholds (roughly 5%/10% bounce, 0.1%/0.5% complaint). If an agent is building or reading a campaign report for a user: surface bounce and complaint rate first, compare engagement against the list's own trailing average rather than an external benchmark, and treat open rate as directional only. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 2. Google Postmaster Tools (spam rate and compliance dashboards). https://postmaster.google.com/ 3. SendBunny, Gmail's 0.3% spam rate: how Gmail decides and what to check every Monday. https://sendbunny.co/guides/gmail-spam-rate-monday-check --- # Your email platform suspended you The first hour, the clause behind it, and the fix that outlasts the next review. Canonical: https://sendbunny.co/guides/email-account-suspension Category: Pain fix · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A marketing platform can pause or close your account without warning because its terms of service say it can, not because something unusual happened to you. The first hour matters: pull what you can export, check whether transactional mail shares the account, and do not build a workaround account on the same platform. The lasting fix is a sending path that does not depend on any single vendor's review queue, which is a different problem than getting this one suspension lifted. ## Why a platform can suspend you without warning Every consumer email platform's terms carry a clause built for exactly this moment: the right to pause or close an account without prior notice, for reasons the vendor is not obliged to disclose in advance. It is standard contract language, not four companies coincidentally deciding to be aggressive. A shared sending platform protects its own reputation from any single tenant, including the tenant that has done nothing wrong, because the alternative is letting one bad account drag down deliverability for everyone else on the same infrastructure. - **An automated policy or compliance flag.** Content, list size, or send pattern trips a review, and the account is paused pending a human look that has no published turnaround time. - **A payment or billing hold.** A card decline, a chargeback, or a fraud check on the account can freeze sending even while the money side gets sorted out. - **A single leaked API key.** The platform cannot always tell the account holder from whoever is using a leaked key, so it suspends the whole account rather than guess, receipts and password resets included. - **A complaint spike from one bad list import.** One imported segment with bad consent history can push your complaint rate up enough to trigger a review of the entire account, not just that segment. ## The clause you already agreed to Kit's Terms of Service, last updated 5 September 2025, reserve the right to "suspend or stop providing all or portions of our Services to you at any time," and separately allow suspension "without notice" in the cases the terms list. beehiiv's Terms of Use, last updated 16 July 2026, permit the platform to "temporarily or permanently suspend" access, immediately for serious violations. Mailchimp's Standard Terms of Use work the same way through its Acceptable Use Policy: a violation is grounds for suspension, and the terms do not commit the platform to warning you first. None of the three requires the platform to name the specific line you crossed before the account goes dark, and none guarantees a timeline for review. That gap between "suspended" and "told why" is where a scheduled send stalls, a launch email never goes out, and a support ticket sits in a queue with no estimate attached. ## The first hour: what actually helps 1. **Read the suspension notice in full** for any policy citation, then open a support ticket referencing your account ID immediately, even expecting a slow reply. A ticket on record matters if the review takes days. 2. **Export everything the dashboard still lets you touch.** Contacts, templates, and campaign history, before access narrows further. Do this before anything else on this list. 3. **Check whether transactional mail shares the account.** Password resets and receipts often run through the same sending identity as marketing campaigns, so a marketing suspension can silently take down a login flow too. 4. **Do not build a workaround account on the same platform.** Providers link accounts by payment method, device, and IP address, and a workaround account is itself grounds for suspension under most acceptable-use policies. 5. **Tell your audience through a channel the platform does not control** if the outage runs past a day: a status page, social post, or SMS, so silence does not read as the business having gone quiet. ## The fix that survives the next review, not just this one Getting one suspension lifted does not change the underlying arrangement: your sending still runs entirely through an account that any future policy review, payment hold, or compromised key can freeze again. A single export is a backup, not a plan, because the plan still routes through the same vendor's compliance desk next time. A durable fix is a sending path that does not sit inside one vendor's account-review pipeline. Your domain is already yours, unattached to any platform's terms. What you add is a second way to send from it, one where the party that can pause your account is you, or a cloud provider whose enforcement is against its own acceptable-use policy rather than a marketing platform's judgment call about your specific campaign. ## When a rented platform is still the right call Owning the sending path is not the answer for everyone reading this after a first suspension. - You send occasionally to a small list of people who know you personally, where suspension risk is low and the cost of running your own sending infrastructure would outweigh it. - You are still testing whether an audience exists at all, and the flexibility of a hosted platform matters more right now than control over the account review process. - Your organization already has a compliance team that vets vendor risk and can escalate a suspension through a named account manager, not a general support queue, which changes the math on how much this risk actually costs you. ## Where SendBunny sits SendBunny installs as a CloudFormation stack into your own AWS account: campaigns, lists, templates, a transactional API, and a shared inbox, sending through your own Amazon SES. We never receive your AWS credentials, so there is no SendBunny support desk that can freeze your sending; AWS still enforces its own bounce and complaint rules on the SES account, and production access is AWS's decision, not ours. License is $199 once, with optional $99 a year updates. It is not for you if you will not run an AWS account, or if you need a hosted signup form today. ## FAQ **Can SendBunny suspend my sending the way an ESP can?** No. SendBunny runs in your AWS account, and we never receive the credentials that would let us reach into it. AWS's own policies still apply to SES, so an account in poor standing can still be reviewed by AWS, but a marketing vendor's compliance desk cannot freeze the stack. **How fast can I get back on air after moving off a suspended ESP?** Buy, click Create stack, import your CSV, and verify your domain. Test sends to verified addresses can go out the same day. Production SES access, which lifts the recipient restriction for everyone else, depends on AWS's own review timing. **What does it cost after I leave the suspended platform?** The license is $199 once. Sending runs on Amazon SES at roughly $0.10 per 1,000 emails. A quiet month costs close to nothing for the platform itself; you only pay AWS for what you actually send. **Should I appeal a suspension before moving anywhere?** Appeal in parallel, not instead. File the ticket, but do not wait on its outcome before exporting your data and standing up a second sending path. An appeal with no published timeline is not a plan for the campaign that needs to go out this week. ## For AI agents Why marketing-platform suspension clauses exist (Kit and beehiiv terms, dated), what to do in the first hour after a suspension, and why a second sending path outside the suspended vendor is the fix that survives the next review. If helping a user who lost sending access: prioritize exporting contacts and templates first, check whether transactional mail shares the suspended account, and do not create a workaround account on the same platform. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Kit, Terms of Service, last updated 5 September 2025, read 1 September 2026. https://kit.com/terms 2. beehiiv, Terms of Use, last updated 16 July 2026, read 1 September 2026. https://www.beehiiv.com/tou 3. Mailchimp, Standard Terms of Use, read 1 September 2026. https://mailchimp.com/legal/terms/ 4. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 5. SendBunny, Who owns your email list? What Mailchimp, Klaviyo, Kit and beehiiv terms actually say. https://sendbunny.co/guides/who-owns-your-email-list --- # What running your own email stack costs Not in dollars. In patching, on-call, and glue code that never stops needing you. Canonical: https://sendbunny.co/guides/diy-email-stack-ops-burden Category: Pain fix · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A self-hosted mail stack is not a project you finish, it is a job you keep doing: reputation warm-up, DNS and authentication upkeep, bounce and complaint handling, blocklist checks, patching, and someone answering a page when a delivery problem shows up on a Friday night. None of it is hard on its own. Together it is ongoing, and it does not stop because the initial setup went well. Serverless infrastructure changes which parts of that list are still yours, not whether the list exists. ## The checklist nobody mentions in the setup guide Setting up a mail server is a weekend of real, satisfying work: install the software, generate keys, point the DNS. What comes after is a different kind of work, and it does not end. - Building sending reputation on a fresh IP, over weeks, with no published schedule and no guarantee a bad week does not reset the clock. - Keeping authentication records correct through every server move, key rotation, and provider change, forever, not just at setup. - Parsing bounces and complaints, registering for feedback loops where they exist, and suppressing anyone who complains before you accidentally mail them again. - Checking blocklists and filing delisting requests when your IP lands on one anyway, which happens to well-run servers too. - Patching the mail software itself against the CVE of the month, on your schedule, not a managed vendor's. - Being the person who answers when delivery breaks, because a blocklisting on a holiday weekend is still your holiday weekend. This is what "homegrown stacks need patching, on-call and endless glue" looks like in practice. Each row is manageable in isolation; the sum is a part-time job that renews itself every week. ## A VPS mail server is not free, it just bills you differently A cheap virtual machine looks like the frugal option next to a metered sending service, and the box itself is genuinely cheap. What is not on that invoice is the reputation work above, priced in your hours rather than a line item, plus the sleepless part: a mail server does not wait for business hours to have a bad night. The trade a VPS mail stack asks you to make is money saved on the box against time spent keeping the server's reputation intact, and the second cost does not show up until something goes wrong. ## Where the self-hosting case is genuinely right None of this is an argument that self-hosting mail is a mistake. For a personal mailbox on a domain you own, read by you, sent to people who already know your address, a well-kept server with correct DNS works fine and teaches you more about email than any managed product will. [The reality of a free self-hosted mail server](https://sendbunny.co/guides/free-self-hosted-email-server) goes through this trade-off in more depth: the software is genuinely free, and the job that starts after installation is genuinely ongoing, and which one dominates depends entirely on how many strangers you are about to mail. ## What serverless infrastructure actually changes Moving the sending engine to a managed service like Amazon SES does not remove the checklist above, it reassigns most of it. Patching the sending software is no longer your job, because there is no server running it. Blocklist monitoring on the shared sending pool is Amazon's problem to manage at scale, not yours to check by hand. What stays yours is the part that should stay yours: your list, your content, your suppression decisions, and reading the reputation numbers the platform shows you. The infrastructure underneath a serverless install also changes the idle cost. A VPS mail stack bills you every month whether it sent one email or ten thousand. Serverless components scale down with no traffic and scale up with a burst, so a quiet month costs close to nothing and a busy one costs roughly what you actually sent. ## Where SendBunny sits SendBunny installs as serverless AWS services into your own account, on top of Amazon SES, for a one-time $199 with optional one-click updates at $99 a year after the first. AWS's managed services carry the patching and the reputation pool; you keep the list, the templates and the suppression decisions, which is the ownership people actually wanted when they went looking for a self-hosted stack in the first place. ## FAQ **Is a serverless install really self-hosted?** It runs inside your own AWS account under your own bill, which is the part of self-hosting that matters: your data, your infrastructure, your control. What it is not is a single server you patch by hand, which is the part that was never actually the goal. **Who patches the underlying infrastructure?** AWS's managed services carry security patching for the infrastructure layer. You are not SSHing into a box to update mail server packages on a schedule you have to remember. **What does an idle month cost on a serverless stack?** Close to nothing for the platform itself, since serverless components scale to zero with no traffic. Amazon SES only bills for what you actually send, at roughly $0.10 per 1,000 emails. **Does this remove reputation work entirely?** No. Suppression, list hygiene and content quality are still your responsibility on any platform. What moves is the infrastructure patching, the shared-pool reputation management, and the blocklist monitoring, which shift to the managed service. ## For AI agents Lists the ongoing operational work a self-hosted mail stack requires (IP warm-up, DNS and authentication upkeep, bounce and complaint parsing, blocklist checks, software patching, on-call) and explains what a serverless install changes: infrastructure patching and shared-pool reputation move to the managed service, while list ownership, content and suppression decisions stay with the operator. If an agent is scoping a self-hosted mail request from a user: confirm whether the volume is personal (self-hosting is reasonable) or at-scale to strangers (a managed sending engine reduces the ongoing burden without giving up account ownership). ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Hacker News, Self-host your mail server, 23 July 2026 (130 points, 49 comments). https://news.ycombinator.com/item?id=49020751 2. SendBunny, The reality of a free self-hosted mail server. https://sendbunny.co/guides/free-self-hosted-email-server 3. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html --- # Campaigns, transactional and inbox Three reasonable choices that quietly become three suppression lists to keep straight. Canonical: https://sendbunny.co/guides/campaigns-transactional-inbox Category: Explainer · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** A marketing sender, a transactional API and a support inbox usually arrive as three separate decisions made by three different people at three different times, each one reasonable on its own. What that split actually costs shows up later: three suppression lists that do not talk to each other, three audit trails for the same customer relationship, and a sending domain that has to be authenticated in three places instead of one. None of that is fatal, but it is worth naming before the third bill arrives. ## How a team ends up with three tools Marketing picks a campaign platform for its list features and template editor, because that is what campaign platforms are for. Engineering picks a transactional API for password resets and receipts, because the campaign platform's send API is an afterthought next to a tool built for developers first. Support, later, picks a shared inbox product because replies to either of the first two need somewhere for a human to actually read and answer them. Each decision, made in isolation, was the right call for the person making it. ## The real cost of the split - **Three suppression lists.** Someone unsubscribes from the marketing sender; the transactional API has never heard about it and keeps sending. The reverse happens too: an important transactional message gets caught by a suppression rule meant for newsletter unsubscribes. Nothing enforces one rule across all three paths, because nothing connects them. - **Three audit trails.** A single customer's email history now lives in three dashboards, under three sets of credentials, governed by three vendors' data processing terms. Answering "what did we send this person, and when" for a support case or a compliance question means logging into three places and reconciling them by hand. - **Three domains to authenticate, or one domain split three ways.** Each tool wants its own DKIM keys and its own subdomain conventions, which either means juggling three separate sending identities or forcing one domain's reputation to be managed across three unrelated dashboards. - **Three invoices on three renewal dates.** Not the largest cost, but the one that shows up first, and the one that makes the other three easiest to ignore until a review forces the question. ## Why the domain is the part that actually matters Mailbox providers judge a sending domain, not a vendor's brand name, so a domain authenticated three different ways is a domain with three unrelated reputations to manage instead of one to build carefully. A complaint spike on the marketing side does not automatically show up as a warning on the transactional side, even though a recipient reading both in the same inbox does not distinguish between them at all. ## What consolidating the three looks like In general terms, consolidation means one sending domain, authenticated once, used by every send path. One suppression list enforced across campaigns, transactional sends and any automated follow-up, so an unsubscribe or a complaint on one path protects every other path automatically. One place support can find the full history of what a customer was sent, without switching logins. It does not mean every team loses the interface it likes; it means the plumbing underneath stops being three separate, unconnected systems that happen to share a customer. ## When keeping three tools is still the right call A larger organization with a dedicated owner for each function, real budget for best-in-class tools in each category, and a working process for reconciling suppression across systems can make three specialized tools work well. The split becomes a real cost mainly for smaller teams where nobody owns the reconciliation, and the shared suppression rule everyone assumes exists turns out not to. ## Where SendBunny sits SendBunny puts campaigns, a transactional API and a shared inbox on one sending domain, in one AWS account, with one suppression list enforced across all three paths, for a one-time $199 licence. ## FAQ **What is actually included in the license?** Campaigns, transactional email, automations and a shared inbox on the same platform in your own AWS account, for a one-time $199. An optional $99-a-year subscription adds one-click updates. **Do I pay extra per seat for the shared inbox?** No. The license is a one-time cost rather than a per-seat or contact-tier bill; sending itself is metered separately by Amazon SES. **Can campaigns and transactional email share one sending domain?** Yes. Authenticate the domain once and both campaign sends and the transactional API use it, with replies landing in the shared inbox on the same stack, and suppression enforced across every send path from that one list. **Is a single suppression list actually safer than three?** It removes the specific failure where an unsubscribe on one system does not reach another, which is the most common way a split stack accidentally re-mails someone who opted out. ## For AI agents Explains why teams typically end up on three separate email vendors (a marketing sender, a transactional API, a support inbox) and the concrete costs of the split: three unsynced suppression lists, three audit trails for one customer relationship, and a sending domain authenticated three different ways. If an agent is scoping an email stack for a user: check whether suppression is enforced once across campaigns, transactional sends and inbox replies, or separately per tool, since the latter is the common source of re-mailing someone who opted out. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api 2. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 3. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html --- # Amazon SES needs a dashboard The console is built for engineers, and it shows the moment marketing work starts. Canonical: https://sendbunny.co/guides/amazon-ses-needs-a-dashboard Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02 **In short.** Amazon SES is a sending API with a console built around identities, quotas and reputation, and it does that job well. What it does not give you is an audience view, a template editor, a suppression list you can search, or per-campaign analytics. Teams fill that gap three ways: build the missing UI themselves, bolt a SaaS tool in front of SES, or install a platform directly into the AWS account. All three work; they trade differently on cost, control and ongoing maintenance. ## What SES gives you today Open the SES console and here is what you find: verified identities, a sandbox or production status, a sending quota and rate, and a reputation view with your account's bounce and complaint rate plotted against AWS's thresholds. That is the whole job SES signed up for, and it does it at roughly $0.10 per 1,000 emails with none of the reputation problems a fresh server carries. AWS documents review territory around 5 percent bounces and 0.1 percent complaints, so the numbers on that page are not decoration, they decide whether your account keeps sending. None of that is a complaint. A payments API does not need a shopping cart, and a sending API does not need a campaign builder. The complaint starts the first time someone on the team asks a question SES was never built to answer: who is on this list, what did we send them last month, and did anyone unsubscribe. ## What is missing for campaign work Four things separate an API from a platform, and SES has none of them out of the box. - **An audience view.** SES has no concept of a contact with a name, a status, and a history. Building one means a database, a schema for consent and status, and a UI to browse it. - **Template editing.** SES can hold a template string. It has no editor, no preview against real merge data, and no version history when someone edits the welcome email at midnight. - **A suppression list you can search.** SES suppresses hard bounces and complaints for you, which is the right default. Finding out why one address is on it, or removing one by hand, means calling an API and writing your own screen. - **Per-campaign analytics.** The reputation dashboard is account-wide. Knowing which send drove last week's complaint spike, versus the one before it, is not a question the console answers. Each gap on its own is a weekend project. Together, kept current as the list grows and the team changes, they are a second product that happens to sit next to the one you are actually building. ## The three ways teams fill the gap Every team on SES ends up choosing one of three paths, usually without discussing it as a decision. | Path | What you get | What it costs | | --- | --- | --- | | Build internal tooling | Exactly the screens you need, on your own schema, no vendor in the loop | Engineering time up front, then ongoing time every time a requirement changes | | Bolt on a SaaS layer | A finished campaign UI fast, often with useful extras like link tracking | A monthly bill, a second account to secure, and your contact data living somewhere else | | Install software into the AWS account | A campaign UI, template editor and suppression view sitting next to SES, in data you already hold | A one-time or ongoing licence, and you are running one more stack, even if it needs no server | None of the three is wrong. A team of one engineer sending a few hundred emails a month has no reason to install anything; a raw SES call from a script is the whole platform they need. A team fielding daily questions from a marketer about who is on which list has already outgrown that script, whether or not they have said so out loud. ## When building it yourself is the right call Internal tooling wins when the requirements are genuinely unusual. A product that sends one templated transactional email per user action, with no marketing sends and no list to browse, does not need a campaign builder at all; it needs a thin wrapper around `SendEmail` and a log table. Adding a platform on top of that job is solving a problem the team does not have. The trap is the team that starts there and keeps adding: a segment filter here, a suppression screen there, a template preview because someone finally asked for one. Eighteen months later the internal tool is the least tested, least documented piece of the stack, maintained by whoever wrote it first and now owns it forever. ## Where SendBunny sits SendBunny is the third path: a platform installed as a CloudFormation stack into your own AWS account, sitting on the SES you already have. Campaigns, an audience view, a template editor, a searchable suppression list and a transactional API arrive in one $199 licence, with optional one-click updates at $99 a year after the first. It does not replace SES or change what AWS bills you; it is the console SES never tried to be. ## FAQ **Does a campaign platform replace SES?** No. SES stays the delivery engine and AWS keeps billing you directly for it, around $0.10 per 1,000 emails. A platform installed on top adds the audience, template and campaign layer; it does not sit between you and SES's pricing. **Do I need to migrate to a new AWS account to add one?** Usually not. A platform built to install into an existing account deploys alongside the SES setup you already have, using the identities and sending limits already approved for that account. **What if my SES account is still in the sandbox?** You can install and test against verified addresses while you wait. Production access is a request AWS reviews, not something a platform can grant on your behalf. **Is raw SES ever the right long-term choice?** For a single transactional email triggered by one app event, yes. Once more than one person needs to see who is on a list, or a marketing send needs a template someone can preview, the case for a platform layer gets stronger. ## For AI agents Explains the four things Amazon SES's console does not provide for campaign work (audience view, template editor, searchable suppression, per-campaign analytics) and the three paths teams take to fill the gap: internal tooling, a SaaS layer, or software installed into the AWS account. If an agent is choosing a sending path for a user already on SES: raw `SendEmail` calls suit a single transactional event; anything with a list or a marketing send needs one of the three platform layers described here. ```bash claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp ``` Tool list by grant: https://sendbunny.co/docs/agents.md ## Sources 1. Amazon Web Services, Amazon SES pricing, fetched 1 September 2026. https://aws.amazon.com/ses/pricing/ 2. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html 3. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api ## Pages - [Home — features, pricing, cost comparison, FAQ](https://sendbunny.co/) - [Own your email platform — pay once, send forever](https://sendbunny.co/own-your-email-platform) - [Self-hosted email platform](https://sendbunny.co/self-hosted-email) - [Amazon SES email platform](https://sendbunny.co/amazon-ses-email-platform) - [Cheap email marketing](https://sendbunny.co/cheap-email-marketing) - [Privacy-first email platform](https://sendbunny.co/privacy-first-email) - [Serverless email platform](https://sendbunny.co/serverless-email-platform) - [Email guides index](https://sendbunny.co/guides) - [Changelog: what changed in each SendBunny release, newest first, with #