Should password reset emails use a separate provider?

Usually, yes—separating password reset emails from your main marketing/transactional email flow is a good idea, but it doesn’t always mean a completely different vendor.

Recommended approach

Use a separate sending stream and, if possible, a separate subdomain and API key/account for security-sensitive mail like:

• password resets
• email verification
• MFA codes
• account alerts

Why this helps

• Deliverability isolation: A marketing mistake shouldn’t hurt password reset delivery.
• Reputation separation: If one stream gets flagged, the other is less affected.
• Security/control: Easier to lock down credentials and monitor sensitive mail.
• Rate limiting and abuse handling: You can apply stricter rules to reset emails.

Do you need a separate provider?

Not necessarily. Common setups are:

1. Same provider, separate subdomain/sending domain
   Example:

   • news.example.com for marketing
   • auth.example.com for password resets

2. Same provider, separate account/project
   Better isolation, still operationally simple.

3. Different provider entirely
   Useful if you want strong blast-radius separation, regulatory reasons, or if one provider’s deliverability is weak.

Best practice

For most teams:

• Use the same provider
• Separate transactional/security emails from marketing
• Use a dedicated subdomain
• Use a distinct sender identity and API key
• Monitor deliverability separately

When to use a separate provider

Consider a different provider if:

• your marketing emails have inconsistent quality or high complaint rates
• password resets are business-critical and must be insulated from all other mail
• you need redundancy/failover
• compliance or architecture requires hard separation

If you want, I can also suggest a practical email architecture for transactional vs marketing mail.