How to Migrate from SendGrid to Amazon SES (Step-by-Step)

SendGrid has been a go-to email service for years, but rising costs, pricing model changes, and the desire for deeper AWS integration are driving many organizations to Amazon SES. The migration is straightforward when done right — and disastrous when done wrong.

This guide walks you through the migration process step by step, with practical advice from having helped dozens of organizations make the switch without losing a single email to the spam folder.

Why Teams Migrate from SendGrid to SES

Cost

The cost difference is the primary driver for most migrations. SendGrid’s Pro plan starts at $89.95/month for 100,000 emails. SES charges $0.10 per 1,000 emails — that same 100,000 emails costs $10. At higher volumes, the gap widens dramatically.

AWS Integration

If your infrastructure is already on AWS, SES integrates natively with Lambda, SNS, SQS, CloudWatch, S3, and Kinesis. This eliminates webhook complexity, enables real-time event processing, and keeps data within your AWS account.

Control and Flexibility

SES gives you direct control over dedicated IPs, sending configuration, and event processing that SendGrid abstracts away. For engineering teams that want granular control over their email infrastructure, SES provides it.

Pre-Migration Planning

Before changing a single DNS record, plan the migration carefully.

Audit Your Current SendGrid Setup

Document everything you are currently using in SendGrid:

• Sending domains — Which domains and subdomains are configured for sending?
• Authentication — Current SPF, DKIM, and DMARC records (note the selector names)
• Dedicated IPs — How many, and what is their current reputation?
• API integrations — Which applications send through SendGrid’s API? What endpoints and libraries are used?
• SMTP integrations — Which systems use SMTP relay through SendGrid?
• Event webhooks — Where are delivery, bounce, complaint, and click events being processed?
• Templates — Are you using SendGrid’s template engine, or are templates rendered application-side?
• Suppression lists — Export your bounce and unsubscribe lists — you will need these in SES.

Set Up Your SES Environment

Before cutting over, prepare SES in parallel:

1. Request production access — New SES accounts start in sandbox mode (limited to verified addresses). Request production access via the AWS console — approval typically takes 24-48 hours.
2. Verify domains — Add your sending domains to SES and complete domain verification via DNS TXT records.
3. Enable DKIM — Configure Easy DKIM for each domain. SES generates three CNAME records to add to your DNS.
4. Request dedicated IPs — If you are migrating from SendGrid dedicated IPs, request dedicated IPs in SES ($24.95/month each). Decide between managed warm-up pools or manual warm-up.
5. Set up configuration sets — Create configuration sets for event tracking, with event destinations pointing to SNS, CloudWatch, or Kinesis.

Step-by-Step Migration

Step 1: Configure DNS Authentication

This is the most critical step. Get it wrong and your deliverability will suffer immediately.

SPF: SES uses amazonses.com as the sending IP source. Update your SPF record to include SES while keeping SendGrid during the transition:

v=spf1 include:sendgrid.net include:amazonses.com ~all

After migration is complete, remove the SendGrid include.

DKIM: SES Easy DKIM uses its own CNAME records (three per domain). These coexist with SendGrid’s DKIM records during transition — DKIM allows multiple valid signatures.

DMARC: If you have DMARC configured, ensure your policy accommodates both SendGrid and SES during the transition period. A p=none policy during migration reduces risk.

Step 2: Migrate Your Suppression List

Export your bounce, complaint, and unsubscribe lists from SendGrid and import them into SES:

• Hard bounces → Add to the SES account-level suppression list
• Complaints → Add to the suppression list
• Unsubscribes → Handle in your application layer (SES does not have a built-in unsubscribe management system like SendGrid)

Skipping this step is the most common migration mistake. Sending to previously bounced or complained addresses from a new IP will destroy your reputation immediately.

Step 3: Warm Up Dedicated IPs

If you are using dedicated IPs (recommended for volumes over 100,000/month), you must warm them up. A cold IP sending thousands of emails on day one will be throttled or blocked by Gmail, Microsoft, and Yahoo.

Warm-up schedule:

During warm-up, split your sending: warm-up volume goes through SES, remaining volume stays on SendGrid. This parallel sending approach ensures no emails are lost during the transition.

SES also offers managed warm-up pools that handle this automatically — new dedicated IPs are placed in a shared warm-up pool and gradually transitioned to your dedicated pool as they build reputation.

Step 4: Update API Integrations

Replace SendGrid API calls with SES API calls. The interfaces are different:

SendGrid v3 API uses a REST endpoint with JSON payloads and API key authentication.

SES v2 API uses the AWS SDK with IAM-based authentication. If your application already uses the AWS SDK for other services, SES integration is straightforward.

Key differences to handle:

• Authentication — SendGrid uses API keys; SES uses IAM roles and AWS credentials. Use IAM roles attached to your EC2 instances, ECS tasks, or Lambda functions rather than hardcoded access keys.
• Rate limiting — SES has per-second and per-day sending quotas. Request quota increases as needed through the AWS console.
• Template rendering — If you use SendGrid’s template engine, you will need to migrate templates to SES templates, your application, or a templating library.
• Event handling — Replace SendGrid event webhooks with SES → SNS → Lambda/SQS event processing. This is actually more reliable because it uses AWS’s managed messaging infrastructure.

Step 5: Migrate SMTP Integrations

For systems that send via SMTP relay (legacy applications, WordPress sites, transactional email from third-party tools):

• SES provides SMTP credentials generated from IAM users
• The SMTP endpoint is email-smtp.{region}.amazonaws.com on port 587 (TLS) or 465 (SSL)
• Update SMTP settings in each application, replacing SendGrid’s SMTP server, username, and password

Step 6: Set Up Monitoring

Replace SendGrid’s dashboard with SES monitoring:

• CloudWatch metrics — Send, delivery, bounce, and complaint rates with alarms on threshold breaches
• SNS notifications — Real-time alerts for bounces, complaints, and delivery failures
• CloudWatch Logs — Detailed delivery logs for troubleshooting
• SES reputation dashboard — Account-level bounce and complaint rate monitoring

Step 7: Cut Over and Decommission SendGrid

Once your SES dedicated IPs are warmed, integrations are migrated, and monitoring is in place:

1. Route all sending through SES
2. Remove SendGrid includes from your SPF record
3. Monitor deliverability closely for 2-4 weeks
4. Decommission your SendGrid account

Common Migration Pitfalls

Pitfall 1: Skipping Suppression List Migration

Sending to addresses that previously bounced or complained is the fastest way to get your new IPs blocklisted. Always import your suppression lists before sending a single email from SES.

Pitfall 2: Sending Full Volume from Cold IPs

Mailbox providers (Gmail, Microsoft, Yahoo) are skeptical of new IPs sending high volumes. Follow a warm-up schedule. There are no shortcuts.

Pitfall 3: Ignoring DMARC Alignment

If your DMARC policy is set to p=reject and your SPF/DKIM records are not properly configured for SES, your emails will be rejected. Temporarily set DMARC to p=none during migration and tighten it after verification.

Pitfall 4: Not Handling Unsubscribes

SendGrid manages unsubscribe lists. SES does not. You must handle unsubscribe processing in your application layer — list-unsubscribe headers, one-click unsubscribe links, and suppression list management.

Pitfall 5: Hardcoding AWS Credentials

Never embed AWS access keys in application code. Use IAM roles for EC2, ECS, and Lambda. Use AWS Secrets Manager for applications running outside AWS.

Post-Migration Optimization

Once the migration is complete and stable, optimize your SES setup:

• Implement sending analytics — Stream SES events to Kinesis Data Firehose → S3 for long-term analytics on engagement, deliverability by provider, and campaign performance.
• Set up A/B testing — Test subject lines, send times, and content variations using SES configuration sets with different event destinations.
• Optimize send times — Analyze engagement data to identify optimal sending windows for different audience segments.
• Review inbox placement — Use third-party tools (GlockApps, Litmus) to monitor inbox placement at major providers.

Need Help with Your Migration?

Migrating email infrastructure carries real risk — a misstep can affect your sender reputation and deliverability for weeks or months. Our team has migrated organizations sending millions of emails per month to SES without deliverability disruption.

See our SES Migration & Email Delivery Services for details, or learn about our broader AWS SES solutions for ongoing optimization and management.

Contact us to plan your SendGrid to SES migration →