Architecture

What Breaks When Your Auth Email Provider Fails?

One mail provider can sit upstream of signup, recovery, magic links and invitations. Map the dependency to see its real blast radius.

By Adeel Ahmad

Your architecture diagram probably has a box labelled Auth.

That box may be hiding an entire failure path.

If signup confirmation, password recovery or magic links depend on email, the real path is closer to this:

Rendering diagram…
Diagram showing relationships between User, App, Auth service, SMTP provider, Recipient provider / filtering, Inbox, Verification link, Onboarding blocked.

The interesting part is not the number of boxes.

It is that several of them sit outside your application while still controlling whether the user can enter it.

The hidden blast radius

A single email-delivery dependency can affect more than signup.

Depending on your auth design, the same path may control email confirmation, password reset, magic-link login, email change verification and invitations.

That means an SMTP problem can have a wider blast radius than the feature name suggests.

What TenaxStack would look for

Dependency

  • Is an external email provider represented on the map?
  • Is the default/testing provider still present in production?
  • Which auth journeys depend on it?

Limits

  • What rate limits apply?
  • Are they compatible with expected launch and recovery traffic?
  • Are resend/cooldown behaviours understood?

Trust and delivery

  • Is the sending domain authenticated?
  • Can the team see provider acceptance, bounce or suppression events?
  • Is “auth request accepted” incorrectly treated as “email delivered”?

Failure

  • What customer journeys stop when email is degraded?
  • Is there an alert?
  • Is there a support/recovery path?

Supabase currently states that its default SMTP is best-effort and non-production, with a two-message-per-hour limit, while custom SMTP begins with a configurable 30-message-per-hour limit.[1]

A simple risk overlay

Rendering diagram…
Diagram showing relationships between Email provider, Signup confirmation, Password recovery, Magic link, Invitations.

One dependency. Multiple customer journeys. That is a blast radius.

Diagnostic questions

  1. If the email provider stopped delivering for 30 minutes, which customer journeys would fail?
  2. Would your monitoring detect it before support tickets did?
  3. Is your production sender still using a testing/default service?
  4. What happens when launch traffic exceeds the configured email limit?
  5. Can you distinguish an accepted auth request from a delivered email?

Sources

What's next for you?

Add the email provider to your architecture map and connect every journey that depends on it. Then mark its limits, telemetry and failure behaviour. A dependency becomes much easier to manage once its blast radius is visible.