Core difference
Amazon SES is regional and AWS-native. It uses AWS credentials, regional identities, configuration sets, AWS event destinations, templates, account suppressions, and optional receipt rules. MailChannels uses MailChannels API credentials, JSON send payloads, DKIM, Domain Lockdown, HTTPS webhooks, and transactional versus non-transactional suppressions.Feature mapping
| Amazon SES concept | MailChannels concept | Migration approach |
|---|---|---|
SendEmail or SendRawEmail | /send payload | Replace AWS SDK calls with MailChannels API calls. |
| Email identities | from identities | Preserve sender addresses and align them with MailChannels domain authentication. |
| Domain identities | DKIM and Domain Lockdown | Recreate domain authentication and publish MailChannels DNS records. |
| Configuration sets | Runtime settings or account boundaries | Translate event, tracking, and routing intent into application settings or sub-account choices. |
| Event destinations | MailChannels webhooks | Replace SNS, EventBridge, Firehose, or CloudWatch flows with HTTPS webhook consumers where appropriate. |
| Email templates | Application-managed Mustache content | Export templates and move rendering ownership outside SES. |
| Account suppression list | MailChannels suppression list | Recreate suppressions with explicit transactional and non-transactional policy. |
| Receipt rule sets | No MailChannels Email API equivalent | Replace inbound receiving and routing with another architecture. |
Send payload notes
The migration is usually a code-level integration rewrite because SES is often called through an AWS SDK rather than a provider-neutral HTTP client.| Concern | Amazon SES behavior | MailChannels behavior |
|---|---|---|
| Authentication | AWS credential chain and IAM policy | MailChannels API key authentication |
| Regionality | SES resources are regional | MailChannels account or sub-account configuration is not an SES region |
| Send API | AWS SDK operations or raw MIME | JSON /send or /send-async payloads |
| Events | AWS-native destinations | MailChannels HTTPS webhooks |
| Inbound | SES receipt rules | External inbound service |
Template migration
SES templates should be exported and moved into application-owned storage. If the existing application calls SES with template names and template data, replace those calls with application-side template selection and MailChannelsdynamic_template_data.
Suppression policy
Recommended defaults:| Amazon SES source | MailChannels target |
|---|---|
| Account-level bounces and complaints | Suppress as both transactional and non-transactional. |
| Region-specific suppression exports | Merge carefully and deduplicate before importing or recreating in MailChannels. |
| Business preference unsubscribes stored outside SES | Preserve in the source preference system and map to non-transactional suppression when appropriate. |
Event migration
SES event destinations frequently feed AWS-native systems. A MailChannels migration changes both transport and event schema. Plan this as a downstream integration rewrite, not just a webhook URL swap.Inbound migration
SES receipt rules do not map to MailChannels Email API resources. Replace inbound flows with a dedicated receiving provider, an application-managed mailbox workflow, or another AWS-native receiving path that remains separate from MailChannels sending.Cutover checklist
- Inventory every SES region that sends or receives mail.
- Replace AWS SDK send calls with MailChannels API calls.
- Recreate DKIM and domain authentication through MailChannels.
- Move SES templates into application-owned storage.
- Replace event destinations with MailChannels webhook consumers where needed.
- Rebuild inbound receipt-rule workflows outside MailChannels.
- Merge regional suppression lists intentionally.