How to migrate off of SES

Migrating off of Amazon SES usually means one of two things:

1. Move to another email provider for sending transactional/marketing email, or
2. Replace SES usage in your app with your own SMTP/server or different delivery architecture.

Here’s a practical migration plan.

---

1) Inventory your SES usage

Identify everything that depends on SES:

• Sending
  • SMTP credentials
  • AWS SDK SendEmail / SendRawEmail
  • Templates
  • Bulk/transactional email
• Receiving
  • Inbound SES rules / receipt processing
• Events
  • Bounce, complaint, delivery notifications via SNS/EventBridge
• Identity setup
  • Verified domains/emails
  • DKIM/SPF/DMARC
• Configuration
  • Suppression lists
  • Sending limits / dedicated IPs
  • Region-specific setups

This helps determine the target provider and what needs to be rebuilt.

---

2) Choose the replacement

Common alternatives:

• SendGrid — common for transactional + marketing
• Mailgun — developer-friendly APIs, good for transactional
• Postmark — strong transactional focus
• Amazon Pinpoint — if you want to stay in AWS ecosystem
• SMTP relay from another provider — simplest if your app already uses SMTP

Choose based on:

• API vs SMTP support
• Deliverability reputation
• Webhooks for bounces/complaints
• Template support
• Pricing and sending volume
• Compliance / data residency needs

---

3) Recreate the email surface area

If you use SES API

Map SES calls to the new provider’s API:

• SendEmail → provider “send message” endpoint
• SendRawEmail → provider raw MIME send
• templates → provider templates or app-side templating

If you use SMTP

Replace SES SMTP host/port/credentials with the new provider’s SMTP settings.

If you receive email through SES

You’ll need a new inbound email solution:

• Provider inbound parsing/webhooks, or
• Separate mail server / mailbox ingestion flow

---

4) Set up domain authentication

This is critical for deliverability.

Update DNS for the new provider:

• SPF
• DKIM
• DMARC
• Optional: tracking CNAMEs, custom bounce/return-path records

Important:

• Don’t leave SES and the new provider both claiming the same DKIM selectors.
• If you’re sending from the same domain during cutover, coordinate SPF/DKIM carefully.

---

5) Handle bounces, complaints, and suppressions

SES often hides some of this behind its ecosystem, so recreate it:

• Subscribe to provider webhooks or event callbacks
• Update your app’s suppression list
• Stop sending to bounced/unsubscribed users
• Record complaint events for compliance

If you have a global suppression list from SES, export and import it if possible.

---

6) Migrate templates and message formatting

If SES templates are in use:

• Export template content
• Recreate them in the target provider
• Or move template rendering into your app (recommended if you want portability)

Test:

• Plain text
• HTML
• Attachments
• Inline images
• Character encoding
• Reply-to/from names

---

7) Run in parallel before full cutover

Best practice:

• Send a subset of traffic through the new provider first
• Keep SES as fallback temporarily
• Compare:
  • Delivery rates
  • Bounce rates
  • Complaint rates
  • Inbox placement
  • Latency

Start with:

• Internal/staging mail
• Low-risk transactional messages
• A small % of production traffic

---

8) Update application code

Abstract the provider behind an interface, for example:

• EmailSender.send(to, subject, body, ...)
• EmailSender.sendRaw(mimeMessage)

Then swap implementations:

• SES implementation
• New provider implementation

This makes future migrations easier.

---

9) Cut over DNS and credentials

Once confident:

• Update SMTP/API credentials in secrets manager
• Update environment variables/config
• Remove SES-specific IAM permissions
• Remove SES config rules/webhooks
• Update monitoring and alerting

---

10) Decommission SES safely

After a burn-in period:

• Confirm no app paths still call SES
• Remove verified identities if desired
• Delete SMTP credentials
• Remove configuration sets and event destinations
• Clean up domain DNS records related to SES
• Ensure no inbound rules still rely on SES

---

Common pitfalls

• Poor deliverability after switching because new domain/IP reputation is cold
• SPF breaks if too many include: mechanisms or multiple senders conflict
• Missed bounce processing leads to poor reputation
• Hardcoded SES assumptions in code or infrastructure
• Templates differ between providers
• Region mismatch if you used SES in a specific AWS region

---

If you want the easiest path

If your setup is mostly SMTP-based, migration can be as simple as:

1. Choose provider
2. Update SMTP host/port/user/pass
3. Update DNS auth records
4. Rebuild bounce/complaint handling via webhooks
5. Test and cut over

---

If you want, I can give you:

• a provider-by-provider migration checklist
• a SES to SendGrid/Mailgun/Postmark mapping
• or a code example for migrating from SES SDK/SMTP to another provider.