Auth

Sign-up emails never reach real users on Supabase's built-in mailer

Cataloged October 21, 2026 · Lovable · Bolt · Cursor · Replit · v0 · Supabase

Symptom

The sign-up page says check your email for a confirmation link, and nothing arrives. Testing with your own address worked, but real users never get the email, or sign-up fails with email rate limit exceeded. Password reset and magic links break the same way.

Root cause

Every Supabase project starts on a built-in SMTP server that the Send emails with custom SMTP guide says is not meant for production use. Unless a custom SMTP server is configured, Supabase Auth refuses to deliver messages to addresses that are not part of the project's team, and those sends fail with Email address not authorized. The same guide says the default service is limited to 2 messages per hour, a number that can change without notice, with no SLA. The Rate limits page lists the same 2 emails per hour for the built-in provider, counted per project across every email-sending Auth endpoint, and says the limit only becomes configurable with custom SMTP or the Send Email hook. The Error codes page names the two failures: email_address_not_authorized, and over_email_send_rate_limit, returned as 429. A generated app is usually tested by its builder, whose address is a team member, so the flow looks fine until the first outside user signs up. imflawlezz/hackyeah-2026 issue 50, opened October 4, 2026, reports that no real user had ever registered on production: every real /signup in the auth logs failed with 429 over_email_send_rate_limit, the project was on the built-in mailer with Confirm email on, and the app showed the 429 as a generic too-many-attempts message. ssdidiza/spintribe26 issue 39, opened August 11, 2026, reports POST /auth/v1/signup returning 429 over_email_send_rate_limit while the page told users to check their email, so no new member could finish sign-up. YosiefAbraham/family-tree issue 3, opened September 1, 2026, reports the confirmation message showing with no email ever arriving. tekguyz/tekguyz-crm issue 3, opened September 18, 2026, reports an invited sign-up still getting email rate limit exceeded and says custom SMTP is the only way past it. supabase/agent-skills issue 370, opened August 16, 2026, reports two dashboard invitations succeeding and the third failing with 429 email rate limit exceeded. The quick fix several of these threads reach for is turning off Confirm email. The SMTP guide warns against that: do not disable email confirmations under pressure, because attackers can then create accounts in other people's names. It recommends custom SMTP, CAPTCHA protection, and DKIM, DMARC and SPF on the sending domain. Once custom SMTP is saved, Supabase sends to all addresses but starts at 30 messages per hour, which is raised on the Rate Limits page.

Before and after

The before line is the failure the reports describe: the page says check your email even when no email went out. The after line branches on the two Supabase error codes so a delivery failure gets its own message.

Before

if (error) showMessage('Check your email for a confirmation link');

After

if (error?.code === 'email_address_not_authorized' ||
    error?.code === 'over_email_send_rate_limit') {
  showMessage("We couldn't send your email right now.");
}

Fix prompt

In this project and its own Supabase project only. Do not test against any other app or project.

1. Find every place this app sends a Supabase Auth email: signUp, signInWithOtp or magic links, resetPasswordForEmail, resend, and inviteUserByEmail. List each one and the screen that calls it.

2. Read how each call handles errors. If any of them shows a generic message, or tells the user to check their email even when the call returned an error, fix it. Branch on error.code:
- email_address_not_authorized: the project is still on Supabase's default SMTP. Show "We couldn't send your email right now. Please try again later or contact support."
- over_email_send_rate_limit (HTTP 429): show the same message. Do not retry in a loop.
- anything else: keep a generic error.
Only show "check your email" when the call succeeded with no error. Add a cooldown of at least 60 seconds to any Resend or Send link button.

3. Do not turn off Confirm email, and do not set mailer_autoconfirm to true, as the fix. Supabase's SMTP guide warns against disabling email confirmations under pressure.

4. Write a short checklist in the README for the project owner to do by hand in the Supabase dashboard, because these are settings, not code:
- Authentication > Emails > SMTP Settings: enable custom SMTP with a sending service (for example Resend, AWS SES, Postmark, SendGrid, ZeptoMail, or Brevo), a verified sending domain, and a no-reply From address.
- Authentication > Rate Limits: raise the email limit from the starting 30 per hour to what launch traffic needs.
- Set up SPF, DKIM and DMARC for the sending domain with the email provider.
- Turn on CAPTCHA protection for sign-up.
- Keep Confirm email on.

5. Never put SMTP passwords or API keys in client code, a VITE_ or NEXT_PUBLIC_ variable, the repo, or this chat. They go only in the Supabase dashboard.

Do not print tokens, keys, or user rows. Do not edit unrelated files.

Paste this into the coding tool that has your own project open.

2-minute self-check

These steps are for an app you own. Do not run them against someone else's project.

In your own Supabase dashboard, open Authentication > Emails. If it asks you to set up custom SMTP, or SMTP Settings is off, your project is on the built-in mailer, which only delivers to your organization's team members at about 2 emails per hour.
In your own project's Auth logs, search for email_address_not_authorized and over_email_send_rate_limit. Any hit means real sign-up, reset, or magic-link emails have already failed.
Sign up once on your own app with an address you control that is not a member of your Supabase organization, such as a plus alias of a personal inbox. If no confirmation arrives within a few minutes, or the page says check your email while the request returned an error, this is the failure. Delete the test user afterward.

Common questions

Sign-up works when I test it. Why do real users never get the confirmation email?

Your own address is almost certainly a member of your Supabase organization. Supabase's custom SMTP guide says that without a custom SMTP server, Supabase Auth refuses to deliver to addresses outside the project's team, and those sends fail with Email address not authorized. The built-in service is also limited to 2 messages per hour per project. In imflawlezz/hackyeah-2026 issue 50, every real sign-up in the auth logs failed with 429 over_email_send_rate_limit, and no real user had ever registered.

Can I just turn off Confirm email so people can sign up?

Supabase's SMTP guide says not to disable email confirmations under pressure. Bots that flood sign-ups can aim to push you into exactly that, and with confirmation off someone can create an account in another person's name. The documented path is custom SMTP with a verified sending domain, a higher email limit on the Rate Limits page, CAPTCHA protection, and SPF, DKIM and DMARC on the sending domain.