Migration guide

Migrate from SendGrid to Amazon SES

The sending swap is an afternoon. What makes this migration hard is everything SendGrid does that is not sending: unsubscribe groups, Inbound Parse, and the Marketing Campaigns side. Subusers map onto SES tenants. Those three map onto nothing.

This page is the order of operations, the surfaces that have no SES equivalent, and an honest read on who should not do this at all.

Stand up SES SendGrid vs Wraps, side by side

Who should stay on SendGrid

Four situations where the move costs more than it returns, and saying so is cheaper for both of us than a bounced migration.

Inbound Parse is a product feature and not a convenience. SES email receiving runs in a handful of Regions, hands you raw MIME in S3, and the parser becomes yours to write and keep running.
Marketing Campaigns is where your automations, segments, and sign-up forms live. None of that exports.
You are on a Twilio enterprise agreement and email is one line on it. Procurement will cost more than the sending does.
You have no one who wants to own an AWS account. SES production access, bounce-rate thresholds, and Region choices are now your job.

The people this migration serves well are transactional senders with one or two domains, a codebase they control, and a bill that has grown faster than their send volume.

Surface by surface, what actually changes

Read the last three rows first. Those are the ones that turn a migration into a project.

Surface	On SendGrid	On SES
Send call	@sendgrid/mail, or SMTP relay on smtp.sendgrid.net	SESv2 SendEmail, or SMTP on the Region's SES endpoint
Templates	Dynamic templates, Handlebars, edited and stored in SendGrid	SES templates, or render in your own code before sending
Events	Event Webhook, HTTP POST of a batched JSON array	EventBridge or SNS, one event per message, your consumer
Suppression	Global list, plus unsubscribe groups per category	One account-level list holding bounces and complaints only
Inbound	Inbound Parse, parsed body POSTed to your URL	Receipt rules to S3, SNS, or Lambda, in some Regions only
Tenant isolation	Subusers with their own credentials, IPs, and reputation	Tenants, with their own credentials, IP pool, and suppression list
Reputation signal	Per-subuser stats, and the shared or dedicated IP pool	Per-tenant rates that still sum into the account-wide one
Marketing side	Marketing Campaigns, priced as its own plan	Not offered — SES sends what you tell it to send

The migration, in order

Two steps have clocks on them that you do not control: SES production access, and DNS propagation. Both are free to start on day one, so start them on day one.

1
Map your subusers onto SES tenants before anything else
If you send on behalf of customers through SendGrid subusers, this is the step that decides whether the migration takes a week or a quarter. The shape that matches is an SES tenant. Create one per subuser, associate the identity and configuration set it sends through, then name the tenant on the send — the X-SES-TENANT header over SMTP, TenantName on SESv2. Each tenant reports its own bounce and complaint rates, can carry its own suppression list and IP pool, and a reputation policy can pause that tenant on its own rather than stopping the account. Two things do not carry over. Tenants are a paid SES add-on, not something the account has by default, and every tenant's numbers still sum into the account-wide rate AWS enforces on. Isolation here buys a smaller blast radius, not a separate reputation.
2
Export the suppression data while you still have a login
Global unsubscribes, group unsubscribes, bounces, blocks, and spam reports each export as CSV from the Suppressions area. Take all of them. Re-mailing someone who unsubscribed is a compliance problem, not an inconvenience, and SendGrid does not hand this back after you close the account.
3
Verify the domain in SES and open production access
Verify the domain in the SES Region you intend to send from and publish the three DKIM CNAMEs SES gives you. Then file the production access request immediately, before the code work starts. A new SES account is sandboxed to verified addresses, AWS typically answers within a day and longer if it comes back with questions, and it can be refused. Our sandbox guide and production access guide cover what the request has to say to get approved on the first try.
4
Publish DNS for both senders at once
Add the SES records next to the SendGrid ones rather than replacing them. In practice that means adding include:amazonses.com to your SPF record while include:sendgrid.net is still there, and leaving the s1._domainkey and s2._domainkey CNAMEs alone. DMARC needs no change at all — the policy is about alignment, not about who sends. If you use SendGrid link branding, the click-tracking CNAME is the one record you cannot run in parallel; point it last.
5
Rewrite dynamic templates
Dynamic templates are Handlebars documents living in SendGrid's editor, and the export is one template at a time. There is no bulk download. Budget real hours here if you have dozens. Wraps templates are React Email components that sit in your repository and get reviewed in pull requests, which is a different working model, not a converter — nothing automatically translates {{#if}} blocks for you.
6
Swap the send call and the event consumer
Every sgMail.send() call needs a new client. The larger job is usually downstream: anything consuming the SendGrid Event Webhook is reading SendGrid's JSON shape, and SES emits its own event shape through EventBridge. The fields map cleanly enough — delivered, bounce, complaint, open, click — but the payload is not drop-in.
7
Split traffic, then cut over
Route a slice of production traffic through SES for a week or two and watch bounce and complaint rates against the SendGrid baseline you already have. When the numbers match, drop include:sendgrid.net from SPF and remove the SendGrid DKIM CNAMEs. Cancel the account last: a suspended SendGrid account keeps billing until it is explicitly cancelled.

What you lose

SES is cheaper because it is less product. Six things go away the day you cut over, and no tool on top of SES puts the first three back.

Marketing Campaigns. The automations, segments, and sign-up forms are a separate SendGrid product with no export path into anything else.
Unsubscribe groups. The SES suppression list holds bounces and complaints, and has no concept of a per-category opt-out.
Inbound Parse. SES receipt rules deliver raw MIME, are Region-limited, and leave the parsing to you.
The Design Editor. There is no drag-and-drop template builder anywhere in SES.
Account-wide safety margin. AWS watches your bounce and complaint rate across the whole account and can pause sending on it, and per-tenant rates still sum into that number.
First-try approval. SES production access is an application AWS reviews, and refusals on a thin application are common.

What the two of them cost

SendGrid

Essentials $19.95 at 50K and $34.95 at 100K. Pro $89.95 at 100K, $249 at 300K, $499 at 700K. Dedicated IP is Pro and above; extra IPs $30/mo. Marketing Campaigns is priced as its own plan, not an add-on.

The free tier died on 27 May 2025, replaced by a 60-day trial at 100/day. Support latency and abrupt account suspensions dominate its public reviews.

Amazon SES

$0.10 per 1,000 emails on à la carte. New accounts are defaulted to the Essentials plan at $0.16 per 1,000; Pro is $105/mo + $0.22 per 1,000 and Enterprise $500/mo + $0.23 per 1,000. Plans are per-account, per-Region.

Production access is an application AWS can refuse, and new accounts start sandboxed to verified addresses. No dashboard, no templates, and nothing stores your events until you build it.

Prices are what each vendor publishes, verified August 2026. Put your own volume through the SES calculator rather than trusting a ratio from a comparison page, ours included.

Where Wraps fits

Steps three, four, and six above are the ones people abandon on. Wraps is the tool for those, and it changes nothing about who owns the mail.

What it does

wraps email init deploys SES, EventBridge, SQS, Lambda, DynamoDB and scoped IAM roles into your AWS account
wraps email connect adopts SES identities you already have, without touching them
Every resource is namespaced wraps-email-, so nothing existing is modified
Bounce and complaint handling, suppression enforcement, and a per-message event history

What it does not

It does not manage SES tenants. You configure those against SES directly.
It does not do inbound email parsing.
It does not get you production access — that approval is AWS's, usually answered within a day, and refusable.
Contacts, templates, and workflow state live in our database, not your AWS. Only sending data and delivery events land in your account.

Platform fee only: Free ($0/mo), Pro ($29/mo), Business ($199/mo) — priced on AWS accounts, dashboard history, and governance features, not send volume. Sending is billed by AWS directly — $0.10 per 1,000 on SES à la carte, or $0.16 on the Essentials plan new AWS accounts are defaulted to. Contacts are unlimited on every tier.

Questions people ask before they commit

What replaces SendGrid subusers in Amazon SES?

SES tenants. A tenant owns its identities, configuration sets, and templates, reports its own bounce and complaint rates, and can hold its own suppression list and IP pool. Reputation policies pause a single tenant on a threshold breach and leave the others sending. The default ceiling is 10,000 tenants per account per Region and AWS raises it on request. Two differences are worth planning around: tenants are a paid SES add-on, and each tenant's rates still roll up into the account-wide number AWS enforces on.

Does SES have an equivalent of Inbound Parse?

SES email receiving is the closest thing, and it is not the same shape. Inbound Parse POSTs a parsed multipart body to your URL. SES receipt rules take delivery of the raw message and hand it to S3, SNS, or Lambda, and you do the MIME parsing yourself. SES email receiving is also only offered in a subset of Regions, so check yours before you plan around it.

Do I lose my sender reputation when I leave SendGrid?

You keep the domain half and lose the IP half. Mailbox providers score the domain, and that history travels with you. If you were on a SendGrid dedicated IP, that IP is SendGrid's and its warmth does not come with you. Starting on the SES shared pool is usually the right move rather than buying a dedicated IP and warming it from cold.

What happens to my Marketing Campaigns automations?

They do not move. Marketing Campaigns is priced and built as its own product, and its automations, segments, and sign-up forms have no export path into anything else. If those are load-bearing for you, rebuilding them is the migration, and the sending swap is the easy part.

How long does the whole thing take?

For a single-domain transactional sender with a handful of templates, a working day of code, plus the wait on SES production access — usually an AWS answer inside a day, longer if they ask for more detail — plus a week or two of parallel running. Multi-tenant senders on subusers, and anyone with a large Marketing Campaigns footprint, should plan in weeks.

Start with the request AWS has to approve

Verify the domain and file for production access first. Everything else on this page is work you control; that one is a queue you wait in.

Deploy SES with one command Other SendGrid alternatives