SES Migration & Email Delivery Services | FactualMinds

## What is SES Migration?

SES migration is the process of moving transactional and marketing email workloads from third-party providers — SendGrid, Mailgun, Postmark, SparkPost, Mailchimp Mandrill — onto Amazon Simple Email Service (SES). A safe migration includes domain authentication setup (SPF, DKIM, DMARC), production-access approval, IP warmup, suppression-list import, bounce/complaint handling, and parallel-running cutover so sender reputation and deliverability stay intact throughout the transition.

## Why Teams Switch to Amazon SES

Many businesses start with third-party email providers like Mailgun, SendGrid, or SparkPost. As email volumes grow and costs rise, Amazon SES becomes the clear choice for scalable, cost-effective email delivery — but migration requires careful planning to maintain deliverability.

**Cost Comparison:**

- SendGrid: $10-$100/month for 5K-100K emails
- Mailgun: $10-$100/month for 5K-100K emails
- AWS SES: $0.10 per 1,000 emails = $1-$10/month for the same volume
- **Savings at scale**: A company sending 5M emails/month pays $500 to SendGrid but only $50 to SES (90% cost reduction)

Beyond cost, SES offers native integration with AWS services (SNS for bounce handling, CloudWatch for metrics, SQS for async processing), enterprise-grade compliance features (HIPAA, GDPR), and unlimited sending speed.

FactualMinds handles the full migration to SES, including DNS setup, API integration, and bounce tracking, ensuring nothing breaks in the transition.

## Three Migration Paths: Choose Your Approach

Not all SES migrations are equal. Your approach depends on volume, current infrastructure, and risk tolerance:

**Path 1: SMTP Relay Swap (Fastest, Lowest Risk)**

- Your application connects to SES via SMTP (port 587 or 25) instead of SendGrid/Mailgun
- Minimal code changes — usually just update SMTP credentials in config
- Time to migrate: 2-4 hours
- Downside: SMTP is slower than API, higher latency
- Best for: Low-volume transactional email (100K-1M/month), existing SMTP infrastructure
- Example architecture:
  ```
  Your application → AWS SES SMTP endpoint → SES queue → Recipient
  ```

**Path 2: API Migration (Balanced Approach)**

- Your application calls SES API directly (boto3 in Python, SDK in Node/Java)
- Requires code changes to replace SendGrid API calls with SES API calls
- Time to migrate: 1-2 weeks (includes testing and rollout)
- Benefits: Faster delivery, better rate limiting, native error handling
- Best for: Mid-volume email (1M-50M/month), engineering team can dedicate time
- Example architecture:
  ```
  Your application → AWS SDK (boto3) → SES API → SES queue → Recipient
  ```

**Path 3: Full Architecture Rebuild (Most Powerful)**

- Decouple email sending from your application using Lambda + SNS/SQS
- Application publishes email event to SNS topic
- Lambda function subscribes to topic, calls SES API
- Enables retry logic, async processing, cost monitoring per email type
- Time to migrate: 3-6 weeks (significant refactor, but future-proof)
- Benefits: Serverless scaling, decoupled architecture, fine-grained monitoring
- Best for: High-volume email (50M+/month), multi-region deployments
- Example architecture:
  ```
  Your application → SNS email topic → SQS queue → Lambda → SES API → Recipient
  ```

**FactualMinds typically recommends Path 2 or 3** depending on your volume and team capacity. Path 1 works for small-scale operations but will hit performance limits quickly.

## IP Warming Strategy & Timeline

One of the biggest mistakes in SES migration: sending full volume immediately. ISPs (Gmail, Outlook, Yahoo) track sender reputation. A new IP with no history that suddenly sends 1M emails looks like spam.

**IP Warming: Day-by-Day Schedule**
Assuming your baseline is 1M emails/day:

| Day   | Volume Target | Daily Email Count | Typical Results                        |
| ----- | ------------- | ----------------- | -------------------------------------- |
| 1-2   | 10%           | 100K emails       | Establish IP reputation baseline       |
| 3-4   | 25%           | 250K emails       | Monitor bounce/complaint rates closely |
| 5-7   | 50%           | 500K emails       | Most ISPs whitelist your IP by now     |
| 8-10  | 75%           | 750K emails       | Approach normal volume                 |
| 11-14 | 100%          | 1M emails         | Full production send                   |

**Critical monitoring during warm-up:**

- **Bounce rate**: Should be less than 2% for transactional, less than 5% for marketing
- **Complaint rate**: Should be less than 0.1% (ISPs penalize complaint rates heavily)
- **Inbox placement rate**: Use 3rd-party tools (250ok, Return Path) to verify emails land in inbox vs spam
- **SPF/DKIM/DMARC alignment**: Verify all three pass before scaling up

**Post-warm-up maintenance:**

- Monitor sender reputation weekly (your ISP reputation, not just bounce rates)
- Review complaint feedback loop data — remove complainers immediately
- Watch for sudden volume spikes (could trigger ISP filtering); spread over hours if possible
- Maintain bounce list (invalid emails) to avoid repeat sends

Read our detailed guide: [AWS SES IP Warming: 14-Day Migration Timeline](/blog/how-to-migrate-from-sendgrid-to-amazon-ses/)

## SNS/SQS Bounce Handling Architecture

Email bounce and complaint handling is where most SES migrations fail. Without proper bounce processing, you keep sending to invalid addresses and get flagged as spam.

**Problem:** Application sends email, doesn't know if delivery failed. Keeps sending to bad addresses. ISP sees pattern, blocks IP.

**Solution: SES → SNS → SQS → Lambda pipeline**

```
1. SES sends email
2. Email bounces (hard or soft)
3. SES publishes bounce event to SNS
4. SNS forwards to SQS queue
5. Lambda polls SQS
6. Lambda updates your database (marks email invalid)
7. Future sends skip that email address
```

**Setup steps:**

1. Create SNS topic (`ses-bounces-topic`)
2. Create SQS queue (`ses-bounces-queue`)
3. Subscribe SQS to SNS topic
4. Enable SES event publishing for bounces (SNS → ses-bounces-topic)
5. Create Lambda function that:
   - Reads from SQS queue
   - Parses bounce event (extracts email address, bounce type)
   - Updates your database (mark user as invalid_email: true)
   - Optionally sends admin alert for repeated bounces
6. Attach Lambda to SQS with poll frequency every 5 minutes

**Bounce types to handle:**

- **Permanent (hard bounce)**: Invalid address, domain doesn't exist, user unsubscribed — remove immediately
- **Transient (soft bounce)**: Mailbox full, server temporarily down — retry after 24-48 hours
- **Complaint**: User marked as spam — unsubscribe immediately

**Cost-effective bounce handling:**

- Batch bounce processing (don't call database for every bounce, collect 100+ before update)
- Retain SQS messages for 1 hour; set Lambda visibility timeout to 30 seconds
- Add CloudWatch alarms if bounce rate exceeds 5% (signals deliverability problem)

## Real-World Case Study: TargetBay 200M Email Migration

FactualMinds migrated TargetBay (e-commerce platform) from SendGrid to SES, handling 200M emails/month. Results:

- **Cost reduction**: $20,000/month to $2,000/month (90% savings = $216K/year)
- **Delivery improvement**: 97% → 99.2% inbox placement rate (fewer emails flagged spam)
- **Time to migrate**: 3 weeks (Path 3: full SNS/SQS/Lambda architecture rebuild)
- **Key success factors**:
  - Phased warm-up schedule (took full 14 days despite lower volume)
  - Proper bounce handling (Lambda updated suppression list in real-time)
  - Complaint monitoring (complained addresses removed within 1 hour)

## Common Challenges We Solve

**Fixing Deliverability Issues** — We fix failed authentication (SPF, DKIM, DMARC), warm up your IPs, and improve your sender reputation so emails land in inboxes, not spam.

**Improving Email Visibility** — With real-time tracking via SNS and SQS, you get clear insights into bounce rates, complaints, and delivery status so problems do not go unnoticed.

**Meeting Compliance Requirements** — We configure SES to meet privacy laws like GDPR, HIPAA, and CAN-SPAM with DMARC reports, audit logs, and hardened email settings.

**Managing Dedicated IPs** — We help you manage dedicated IPs with domain warm-up plans and integrate SES with your marketing platforms and CRMs for seamless operations.

## Frequently Asked Questions

**How long does a typical SES migration take?**

- Path 1 (SMTP swap): 1-2 days
- Path 2 (API migration): 2-4 weeks
- Path 3 (full rebuild): 3-6 weeks
  Typical migrations are completed within 2-4 weeks depending on approach and email volume.

**Can you integrate SES with our existing marketing tools?**
Yes. We help you integrate SES with Mailchimp, HubSpot, Salesforce, and other platforms.

**Will migration affect our sender reputation?**
No. We implement a proper IP warming strategy to preserve and improve your reputation throughout the transition.

**Do you offer ongoing support after migration?**
We offer optional monitoring and deliverability support on a monthly retainer to keep your email infrastructure performing at its best.

**What's the difference between shared and dedicated IPs?**

- **Shared IP**: Low cost, but reputation affected by other senders. Fine for less than 1M emails/month
- **Dedicated IP**: Higher cost ($25-$100/month), but your reputation is yours alone. Necessary for more than 5M emails/month

**How do we handle bounce lists and unsubscribes?**
We implement SES suppression lists (integrated with SNS/SQS) to automatically prevent sends to bounced/complained addresses. GDPR-compliant unsubscribe handling is built in.

1. SES sends email
2. Email bounces (hard or soft)
3. SES publishes bounce event to SNS
4. SNS forwards to SQS queue
5. Lambda polls SQS
6. Lambda updates your database (marks email invalid)
7. Future sends skip that email address