Switching Transactional Email Providers With Zero Downtime

Switching the service your app uses to send password resets and receipts sounds like a weekend job: change an API key, swap a client library, deploy. Then the first customer can't log in because their reset email went to spam, and you discover that nobody exported the suppression list.

A provider switch can be boring and safe if you treat it as a gradual rollout rather than a single cut-over. Here's the sequence.

Why teams switch#

The reasons vary: cost at a new volume, a feature you need (inbound handling, better logs, replies landing in a team inbox), support quality, consolidating vendors, or deliverability problems you've traced to the provider. The reason affects what you test, but the mechanics are the same.

Step 1: Put a thin interface in front of sending#

If provider-specific code is scattered across your app, start here. Create one internal function or module that every part of the app calls to send email, and make it the only place that knows which provider exists.

// email/send.ts
export interface OutboundEmail {
  from: string;
  to: string;
  subject: string;
  html: string;
  text?: string;
  tag?: string; // e.g. "password-reset"
}

export async function sendEmail(msg: OutboundEmail) {
  const provider = pickProvider(msg); // old or new, see step 4
  return provider.send(msg);
}

This is worth doing even if you never switch again. It makes testing easier, gives you one place to add logging, and keeps future changes small.

Step 2: Authenticate the new provider alongside the old one#

Your domain's DNS can authorize both providers at once. Do this days before any mail moves.

• DKIM: each provider signs with its own key under its own selector, so both can be published at the same time. Add the new provider's DKIM record without touching the old one.
• SPF: add the new provider's include to your existing SPF record. Watch the limit of ten DNS lookups; if you're close, remove includes for services you no longer use.
• Return-path or bounce domain: some providers ask for a CNAME on a subdomain to handle bounces and align SPF. Set it up now.
• DMARC: no change needed if both providers pass DKIM with your domain aligned. Your DMARC aggregate reports will show the new provider's traffic once it starts.

Verify with the new provider's dashboard and a DMARC check before sending anything real.

Step 3: Move your suppression list#

This is the step teams skip and regret. Your old provider has a list of addresses that hard-bounced, complained or unsubscribed. If you don't carry it over, the new provider will happily send to all of them, your bounce and complaint rates will spike, and your new sender reputation starts off damaged.

• Export hard bounces, spam complaints and any unsubscribes from the old provider.
• Import them into the new provider's suppression list, or into your own database if you keep suppression in-app.
• Decide how you'll keep both in sync during the overlap. The simplest option is to handle bounce and complaint webhooks from both providers and write to one shared table in your app.