How do I route critical emails through a fallback provider?

A common way to route critical emails through a fallback provider is to use a primary/secondary mail delivery setup with automatic failover.

Basic approach

1. Send normally through your primary provider for all email.
2. Detect delivery failures:
   • API errors
   • SMTP connection failures
   • provider downtime
   • webhook/bounce events
3. Retry critical messages via a secondary provider if the primary is unavailable.
4. Only use fallback for messages that are truly critical, to avoid duplicates and cost spikes.

Recommended architecture

Option 1: App-level failover

Your application decides which provider to use.

• Try primary provider first
• If it fails immediately or is down, send the same email via fallback provider
• Record the message ID and provider used

Good for:

• transactional alerts
• password resets
• account/security notifications

Option 2: Queue-based routing

Put critical emails on a queue and have a worker:

• attempt primary send
• on failure, requeue to fallback
• mark the message as delivered once one provider succeeds

This is usually the safest pattern because it:

• handles transient outages
• supports retries/backoff
• prevents losing emails during incidents

Important considerations

Avoid duplicate sends

If the primary provider may have accepted the message even though your app got an error, use:

• idempotency keys
• message deduplication
• a delivery status check before resending

Separate sending domains/subdomains

Use distinct sending identities if possible:

• mail.yourdomain.com for primary
• fallback.yourdomain.com or another authenticated setup for secondary

Make sure both have:

• SPF
• DKIM
• DMARC

Warm up the fallback provider

Don’t wait until an outage to configure and verify the secondary provider:

• authenticate the domain in advance
• verify templates
• test deliverability
• set up monitoring

Decide failover rules

Typical rules:

• fail over on 5xx/API timeout
• fail over after N retries
• don’t fail over on invalid recipient/content errors
• don’t resend if the primary already accepted the email

Example flow

1. Critical email is created.
2. System sends via primary provider.
3. If primary returns timeout/503, retry once.
4. If still failing, send via fallback provider.
5. Log which provider succeeded.
6. Notify ops if failover rate increases.

Best practice

For critical email, use:

• primary provider
• secondary provider
• queue + retry
• monitoring/alerts
• idempotency

If you want, I can also show:

• a Node.js/Python example for failover
• an SMTP vs API routing pattern
• a Cloudflare/SES/SendGrid style setup