How to migrate off of Resend

Migrating off Resend usually means 3 parts:

1. Replace the API calls / SDK
2. Move or recreate templates, domains, and deliverability setup
3. Switch traffic safely without breaking email sends

Here’s a practical migration checklist.

---

1) Inventory what you use in Resend

Before switching providers, list:

• Transactional emails: password reset, receipts, alerts, etc.
• Marketing/broadcasts: newsletters, campaigns
• Templates: HTML/React email templates, dynamic variables
• Sending domains: DNS records, DKIM, SPF, DMARC
• API usage: SDK, REST calls, webhooks
• Logs / metrics: delivery, bounces, complaints
• Suppression lists / unsubscribes

This helps avoid surprises.

---

2) Pick the replacement provider

Common alternatives:

• Postmark: excellent for transactional email
• SendGrid: broad features, more complex
• Mailgun: flexible API, good for dev-heavy teams
• Amazon SES: cheapest at scale, more setup
• Brevo / MailerLite / Customer.io: if you also need marketing automation

Choose based on:

• transactional vs marketing
• cost
• API simplicity
• deliverability
• required compliance/features

---

3) Abstract your email layer

If your app directly imports Resend everywhere, migration is harder.

Create a small internal interface like:

• sendEmail({ to, subject, html, text, from })
• sendTemplate({ templateId, data })

Then implement:

• ResendEmailProvider
• PostmarkEmailProvider / SesEmailProvider / etc.

This lets you swap providers later with minimal code changes.

Example pattern

interface EmailProvider {
  sendEmail(input: {
    to: string | string[];
    from: string;
    subject: string;
    html?: string;
    text?: string;
  }): Promise<void>;
}

---

4) Recreate templates

If you use Resend React Email templates:

• Export the template markup
• Convert to your new provider’s format if needed
• Test rendering in real inboxes

Things to check:

• dynamic variables
• inline styles
• images/assets
• localization
• unsubscribe links
• plain-text fallback

If your new provider doesn’t support the same templating system, keep templates in your app and send raw HTML.

---

5) Move domain authentication

Set up the new provider with the same sending domain or a new subdomain.

Typically you’ll need:

• SPF record
• DKIM records
• DMARC record
• optionally custom tracking domain

Important:

• You can often keep the same domain, but verify your old provider isn’t still using conflicting DNS records.
• If you’re doing a gradual migration, use a separate subdomain like mail.example.com or txn.example.com.

---

6) Update API keys and secrets

Replace:

• RESEND_API_KEY
• webhook secrets
• environment configs

with the new provider’s credentials.

Make sure secrets are updated in:

• local env
• staging
• production
• CI/CD
• serverless configs

---

7) Rebuild webhooks / event handling

If you use Resend webhooks for:

• delivered
• bounced
• complained
• opened/clicked
• unsubscribed

Then recreate these handlers in the new provider.

Map old event names to new ones and update downstream logic:

• suppress users after bounce
• track delivery status
• update analytics
• remove unsubscribed recipients

---

8) Test thoroughly in staging

Test:

• simple text email
• HTML email
• template rendering with real data
• attachments
• multiple recipients
• failure cases
• bounce handling
• unsubscribe flow

Check inbox placement in:

• Gmail
• Outlook
• Yahoo
• Apple Mail

---

9) Migrate safely with dual sending if needed

For low-risk migration:

• Keep Resend live
• Add new provider behind a feature flag
• Send a small percentage of traffic through the new provider
• Compare success rates, bounces, and rendering
• Cut over gradually

Example:

• 5% new provider
• 50%
• 100%

This is especially useful for high-volume transactional email.

---

10) Preserve compliance and user preferences

Make sure you carry over:

• unsubscribe preferences
• suppression lists
• consent records
• bounce/complaint suppression
• regional compliance settings

If you lose these, you may accidentally email people who opted out.

---

11) Decommission Resend carefully

After the cutover:

• Keep Resend active for a short rollback window
• Monitor logs and support tickets
• Verify no cron jobs, background tasks, or old services still call Resend
• Then remove:
  • API keys
  • DNS references
  • webhook endpoints
  • old code paths

---

If you want the fastest path

The simplest migration is usually:

1. Wrap Resend behind an internal email service
2. Implement the same interface for the new provider
3. Swap credentials and DNS
4. Test and cut over with a feature flag

---

Common pitfalls

• forgetting plain-text email bodies
• not migrating suppression/unsubscribe lists
• breaking templates with provider-specific syntax
• mismatched DNS records
• not updating webhook consumers
• accidentally using old “from” domains that haven’t been authenticated

---

If you want, I can give you a provider-by-provider migration guide for:

• Resend → Postmark
• Resend → SES
• Resend → SendGrid

or help you design a provider-agnostic email abstraction in code.