Supabase
Supabase auth email not sending
The client can report a successful signup while no email leaves, or the email leaves and the link is refused because the redirect URL is not allowed.
Symptoms
- The first signups of the day arrive. Later ones do not.
- The Auth log shows a user, and no email, or an email error.
- The email arrives and the link errors or returns to localhost.
- You expected a confirmation email and confirmations are turned off.
Common causes
The built-in mailer is rate-limited
Supabase includes a mailer so you can try auth. It is not a production sender, and it throttles. A launched app looks fine in testing and then stops emailing real signups.
Custom SMTP is missing or rejected
Production email needs your own SMTP. A wrong host, port, or sender means the Auth log has an error and the user still sees a generic signup failure, or a success, depending on the client.
The redirect URL is not allowed
The link in the email uses the redirect you passed, or the site URL. If that URL is not on the allow-list, the person clicks through and Supabase refuses the redirect. Add the production URL, not only localhost and the preview host.
Site URL is still localhost
Templates that use the site URL send people to your laptop. Change the site URL when you attach a domain.
Confirmations are disabled
If email confirmations are off, no email is sent and the user is signed up. That is a setting, not an outage. Turn it on only if you meant to require the click.
The client talks to another project
The anon key and URL in the deployed app belong to a different Supabase project, often a sample. You are inspecting the project that never received the signup.
Fix it
Read the Auth log for this user
Find the signup in the project you think you are using. No user means the client never reached this project. A user with an email error means SMTP or the built-in mailer.
Stop relying on the built-in mailer
Configure custom SMTP before you send real traffic. Send one confirmation to an inbox you control from the project settings and confirm it arrives.
Add the production redirect URL
In Authentication URL configuration, allow the exact origin and path your email link uses. Include https and the custom domain. Remove reliance on localhost for the deployed app.
Set the site URL
Put the public origin in the site URL so templates that use it do not point at a preview or at localhost.
Decide whether confirmation is on
If you do not want a confirmation email, say that in the UI. If you do, turn confirmations on and then test one signup end to end.
Match the anon key to this project
Compare the URL and anon key in the deployed env with the project you are debugging. A copied example env is the usual mismatch.
Catch it automatically
Map the signup flow and assert the “check your email” state. That catches a client that never calls Supabase. It will not read your SMTP provider. Use the Auth log for delivery, and a funnel check so the form itself cannot vanish unnoticed. The Supabase builder page lists the rest of the stack.
Watch the next break before a customer does.
Map the path once. The next publish does not get to fail in private.
Questions
Why did email work yesterday and stop today?
The built-in mailer throttles. Yesterday's test used the quota. Configure SMTP rather than waiting for the limit to reset.
The email arrived and the link failed.
That is the redirect allow-list or the site URL. Delivery worked. Add the URL the link actually opens.
Can FunnelWatch see my Supabase project?
No. It sees the page you ask it to open. It does not get a database password or a service role key.