Migrating from Postmark to AWS SES: When and How

Postmark is the premium option in transactional email — priced accordingly, and genuinely worth it for teams that prioritize deliverability above all else. AWS SES is a commodity infrastructure service priced at cost. The decision to migrate is fundamentally about whether the cost savings justify building the operational scaffolding that Postmark handles for you.

This guide gives you the honest trade-off analysis and the step-by-step migration path if you decide to move.

The Cost Difference Is Stark

No other comparison in the transactional email space has this wide a price gap at volume.

SES dedicated IPs ($24.95/IP/month) add some cost, but even with two dedicated IPs, SES is 3–6x cheaper than Postmark at 500K+ emails per month.

Message Streams vs SES Configuration Sets

Postmark’s message streams are its most distinctive feature. Each stream has its own dedicated IP pool, separate bounce/complaint tracking, and isolated reputation. You create a transactional stream and a broadcast (marketing) stream, and Postmark ensures that a complaint spike on your broadcast stream cannot damage your transactional inbox placement.

SES does not have a native message stream concept, but you can replicate the isolation:

The functional result is the same, but Postmark enforces the separation automatically. With SES, your application must consistently pass the correct ConfigurationSetName parameter on every send.

Template Migration

Postmark templates use Mustache syntax with conditionals, layouts, and partial includes. SES templates support basic {{variable}} substitution only.

Best practice: move template rendering to application code before or during the migration.

Recommended libraries:

• React Email — JSX-based email components with Tailwind support
• MJML — responsive email markup language, compiles to HTML
• Handlebars — logic-capable server-side templating for Node.js
• Jinja2 — equivalent for Python stacks

Render the complete HTML in your application, then call SES.sendEmail() with the rendered body. Your templates become code artifacts (version-controlled, testable, provider-agnostic) rather than data stored in a vendor platform.

Message Retention: Postmark’s 45-Day Log vs SES

Postmark retains every message — including full headers, body, and per-recipient event history — for 45 days. You can search by recipient, subject, or message ID and see exactly what was delivered, opened, or bounced.

SES has no equivalent message archive. To replicate this:

1. Enable SES event publishing to S3 via a Configuration Set
2. Use SES receipt rules to store raw inbound messages to S3
3. Index CloudWatch Logs (or send SNS events to CloudWatch) for delivery/bounce/complaint events
4. Optionally, use Athena to query the S3-stored event archive

This setup is more operationally complex than Postmark’s built-in retention, but it is permanent and queryable at scale via SQL.

Deliverability: Where Postmark Has a Real Advantage

Be direct with your stakeholders about this trade-off:

• Postmark’s shared IP pools are heavily curated — they reject senders with poor list hygiene before they can affect other customers’ deliverability
• Postmark’s feedback loops and complaint processing are faster to surface in their UI
• Postmark’s deliverability team actively monitors and intervenes on reputation issues
• SES shared IPs carry the reputation of all SES customers in that pool — a much larger and less curated set

For clean transactional lists (low bounce rates, no marketing email, engaged recipients), this difference is rarely observable in practice. For teams with variable list quality or mixed transactional/marketing sends, Postmark’s isolation is a real deliverability advantage.

Migration Checklist

1. Verify sending domain in SES (DKIM CNAME records, optional MAIL FROM)
2. Request SES production access (AWS support case with use case and volume estimate)
3. Create two Configuration Sets: one for transactional, one for broadcast (if applicable)
4. Provision dedicated IPs if reputation isolation is required ($24.95/IP/month)
5. Configure SNS event destinations on each Configuration Set for bounces, complaints, and deliveries
6. Implement SNS → Lambda event handler to process bounce/complaint events and update your suppression store
7. Migrate templates from Postmark to application-rendered HTML (React Email, MJML, or Handlebars)
8. Export Postmark suppression list and import hard bounces/complaints to SES account-level suppression list
9. Update SDK calls or SMTP config to point at SES
10. Run parallel sends at 5–10% volume for 1–2 weeks while monitoring bounce and complaint rates
11. Warm dedicated IPs gradually if using them (30-day ramp to full volume)
12. Shift remaining traffic to SES and close Postmark account

When to Stay on Postmark

The migration is not always the right call:

• Your email volume is under 30,000 emails/month — the savings do not justify the engineering investment
• Your team lacks AWS experience and cannot operate SNS pipelines reliably
• Deliverability is a critical business metric and your list quality is variable
• You need Postmark’s 45-day searchable message history for support or compliance workflows
• Non-technical team members manage email templates and need Postmark’s template editor

When SES is the Right Move

SES is clearly the right choice when:

• You send more than 100,000 emails per month and the $80–$700/month savings are material
• Your application stack is already on AWS (Lambda, ECS, EC2) — IAM auth and CloudWatch integration are native
• Your engineering team has AWS experience and can build and operate SNS/Lambda event pipelines
• You want to consolidate vendors and reduce third-party dependencies

FactualMinds is an AWS Select Tier Consulting Partner. Our AWS SES consulting service covers the full Postmark-to-SES migration: domain setup, Configuration Set design for stream isolation, SNS event pipeline implementation, template migration, and IP warming strategy. Contact us to discuss whether the migration makes sense for your volume and team.