# Migrate to Amazon SES

Source: https://wraps.dev/migrate

Moving to SES is mostly the same five moves whoever you are leaving: republish DNS, get out of the sandbox, carry the suppression list across, port the templates, swap the client. What differs is the one feature your provider had that SES does not.

Each guide leads with that feature, and each one opens by saying who should stay where they are.

## Pick your provider

### SendGrid

Hardest part: Marketing Campaigns

Subusers map onto SES tenants, but Inbound Parse, unsubscribe groups, and the Marketing Campaigns side all need somewhere else to live.

[Read the guide](https://wraps.dev/migrate/sendgrid)

### Mailgun

Hardest part: Routes and the Region

Every domain is pinned to the US or EU endpoint, three suppression lists collapse into one, and expression-matched Routes become Region-limited receipt rules.

[Read the guide](https://wraps.dev/migrate/mailgun)

### Postmark

Hardest part: Message Streams

The wall between transactional and broadcast disappears, inbound parsing becomes raw MIME, and under about fifty thousand a month the money argument does not hold.

[Read the guide](https://wraps.dev/migrate/postmark)

### Resend

Hardest part: Knowing whether to bother

Resend already runs on SES, so SPF often needs no change and React Email templates move unedited. Under about a hundred thousand a month, staying is usually cheaper.

[Read the guide](https://wraps.dev/migrate/resend)

### Amazon Pinpoint

Hardest part: A deadline

AWS ends support on 30 October 2026. Email moves to SES; segments, campaigns, journeys, and analytics have no direct successor.

[Read the guide](https://wraps.dev/migrate/amazon-pinpoint)

## True of every one of them

Five facts that hold no matter who you are leaving. The individual guides do not repeat them at length, so read them once here.

### Production access is the long pole

A new SES account is sandboxed to verified addresses. Getting out is an application AWS reviews, typically answering within 24 hours and taking longer if it asks for more information, and it can be refused. File it on day one of any migration, before the code work starts.

### Publish DNS for both senders at once

Add the SES DKIM records and SPF include alongside the incumbent's rather than swapping them. Remove the old records after traffic has moved. DMARC never needs to change.

### Your domain reputation travels, your IP reputation does not

Mailbox providers score the domain, and that history follows you. A dedicated IP at your old provider stays with them. Most senders should start on the AWS shared pool rather than warming a new dedicated IP from cold.

### Export suppressions before you cancel anything

Every provider hands these back while you are a customer and not afterwards. Re-mailing someone who unsubscribed is a compliance problem, and SES only stores bounces and complaints, so the opt-outs need a home of their own.

### Reputation becomes account-wide

SES measures bounce and complaint rates across the whole account, per Region. SES tenants give each stream its own metrics, suppression list, and pause switch as a paid add-on, but every tenant's numbers still sum into the account rate AWS enforces on.

## Still deciding rather than migrating

These guides assume you have already chosen to leave. If you have not, the ranked lists and head-to-head pages are the better starting point.

[Alternatives, ranked](https://wraps.dev/alternatives)[Head-to-head comparisons](https://wraps.dev/compare)[SES cost calculator](https://wraps.dev/tools/ses-calculator)

## The SES half, in one command

Whichever guide you are reading, the sending stack is the same work. Wraps deploys SES with its event pipeline into your own AWS account, or adopts the one you already have without touching it.

[Deploy SES](https://wraps.dev/docs/quickstart/email)[General migration guide](https://wraps.dev/docs/guides/migration)