# 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