Supabase auth email not sending? Find the failed stage first.

A user presses “Create account.” Your app displays a friendly message. Nothing appears in their mailbox. It is tempting to replace the email provider immediately. But that symptom spans several different systems, and a provider switch may leave the real fault untouched.

Start with one owner-controlled test account and one chosen action. Write down when it happened, which environment handled it and what the app was expected to do. Keep passwords, tokens and complete authentication URLs out of shared notes. The aim is to find the first stage with missing or contradictory evidence.

1. Did the app request the intended action?

A success message in the interface is not evidence that the correct project received a signup or reset request. Check whether the app reached the expected Supabase project and inspect the returned result. Some interfaces intentionally keep account-related messages neutral; others may display success without checking an error. You need the actual event, not a conclusion based on the button label.

If there is no corresponding request, or the app invokes the wrong operation, this is an application problem. Writing the missing request or repairing session logic is a different job from configuring SMTP. Note the boundary before changing mail settings.

2. What does Auth report?

Read the project’s Auth logs around the recorded time. Supabase’s troubleshooting guide recommends this before inspecting the email provider. An authentication error can prevent the request from ever reaching SMTP. Keep the exact error category and timestamp, but redact personal data and sensitive URL parameters.

The default sender has intentionally limited use. Supabase currently restricts it to addresses belonging to the project’s team and documents a two-message-per-hour limit. An owner who tests only with a team address may therefore observe different behavior from a new customer. This is a reason to verify configuration, not proof that every Supabase site needs a repair.

Custom SMTP has its own configured limits, and the provider has separate account and sending limits. “Rate limit exceeded” should prompt you to identify which limit applies. Do not repeatedly trigger requests, disable safeguards or remove email confirmation simply to get a green result.

3. Did the provider accept the message?

Once Auth hands the message over, inspect the provider’s event record. Is there an accepted request? A rejected sender? An account restriction? A bounce or suppression? Each leads to a different next action. A message absent from the provider’s records is different from a message it deliberately did not deliver.

Verify that you are looking at the right account, project and time window. If a sender was recently changed, the wrong dashboard can make a successful handoff appear missing. Record the event identifier in your private operational notes; share only the minimum evidence needed with a helper.

Suppression is not a setting to bypass. A previously bounced address may remain suppressed for a reason. Follow the provider’s documented review process and the recipient’s wishes rather than trying another sender to force delivery.

4. What happened at the mailbox?

Provider acceptance is not the same as a visible inbox message. Ask the owner of the test mailbox to check the actual result: inbox, spam, quarantine, delayed receipt or no observed receipt. Enterprise email systems may apply rules outside the app owner’s control.

Supabase’s documentation explicitly separates provider handoff from downstream delivery. If the provider has useful delivery or bounce evidence, use that to decide whether the next step belongs to the provider or the recipient’s administrator. A configuration service cannot guarantee what every receiving system will do.

5. Did the action complete?

Receipt is still not the finish line. Does the signup confirmation complete? Does the reset flow reach the existing password form and save the new password? Does a magic link create the intended session? Test only the path you agreed to check. A broken callback after receipt should not be labeled an SMTP failure.

Keep the message observation and action result as separate fields. That makes the next handoff precise: “Provider accepted, mailbox received, callback failed” is more useful than “Email broken.” Our auth-path test guide shows how to define that result before work starts.

A short evidence sheet

Choose the next job, not a bigger promise

If the evidence points to owner-ready sender configuration, the native integration may be enough. If you want help coordinating and testing it, prepare a free readiness brief. If it points to missing application behavior, agree that separate scope first. Neither an unanswered test email nor a technology marker establishes a general security failure.