Strategy
The fastest safe migration is to change one surface at a time:
- Swap the submission layer (API or SMTP)
- Validate deliverability and outcomes
- Move event ingestion to SendLib webhooks
- Turn off SES sending paths
This keeps risk bounded: you can cut over sending without rewriting your entire analytics/event pipeline on day one.
Phase 1: Choose your submission method
SendLib supports both REST and SMTP. If you're currently using SES SMTP, the lowest friction path is SMTP. If you're using SES APIs (SendEmail/SendRawEmail) and want richer control, move to REST.
Pick one per service
It's fine to have one system use REST and another use SMTP. What's important is consistent observability and suppression handling.
Phase 2: Map concepts
| SES concept | SendLib concept |
|---|---|
| Verified Identity (domain/email) | Verified sending domain |
| Configuration Set / Event Destinations | Webhooks + Events API |
| Bounce/Complaint SNS notifications | Webhook events + suppression automation |
| Sending limits / account throttles | Rate limits + pacing controls |
Phase 3: Cut over sending
Recommended cutover steps:
- Verify your sending domain in SendLib and publish DNS records.
- Create a scoped API key (or SMTP credentials).
- Ship a dual-write (optional): send a small % through SendLib while keeping SES as fallback.
- Ramp traffic over days, not minutes.
Phase 4: Move events
If you currently consume SES events (SNS → SQS/Lambda), migrate to SendLib webhooks:
- Verify signatures
- Acknowledge quickly (
2xx) and do heavy work asynchronously - Deduplicate by message/event id
Common pitfalls
- No idempotency on retries: can cause duplicate sends during cutover.
- Mixing marketing + transactional traffic during warmup: hurts reputation.
- Missing suppression automation: repeatedly sending to hard bounces will tank inboxing.
Next
- Send mail: Transmissions
- Stream outcomes: Webhooks
- Deliverability checklist: Deliverability basics