Your users aren't getting Supabase sign-up emails. It worked when you tested it. Here's why.

You sign up with your own email: the confirmation arrives. A real user signs up: nothing. No confirmation, no password reset, no magic link. Lovable, Bolt and many other AI builders use Supabase for logins, so this is one of the most common problems right after launch, and it usually has nothing to do with your code.

The cause: Supabase's built-in sender is only for testing

Every Supabase project comes with a built-in email sender, so logins work from the first minute. It has two limits that are easy to miss:

• It only sends to your team. Supabase refuses to send to any address that isn't a member of the project's team. You're on the team, so your test worked. Your users aren't.
• Two emails an hour. For the whole project, not per user. The third person to sign up in an hour gets nothing.

Supabase calls it best-effort, with no promise of delivery, and recommends your own email sender for anything beyond trying things out.

The fix: send through your own email service

Supabase calls this custom SMTP. It takes about 15 minutes, and most services are free for the number of emails a new app sends.

1. Pick an email service. Resend, Brevo, Postmark, Amazon SES and SendGrid all work with Supabase. Create an account and find its SMTP details: host, port, username and password.
2. Verify your domain with it. The service gives you a few DNS records (SPF, DKIM and usually DMARC) to add where your domain is managed. They prove the emails really come from you, which keeps them out of spam.
3. Add it in Supabase. In Authentication, open the SMTP settings, turn on custom SMTP and fill in the host, port, username and password, a sender address like no-reply@yourdomain.com, and a sender name people will recognise.
4. Raise the limit if you need to. With your own sender, Supabase starts at 30 emails an hour. If you expect more sign-ups than that, change it under Authentication → Rate Limits.
5. Test from outside the team. Sign up with an address that isn't on the project, like a friend's or a fresh Gmail, and try a password reset too.

Still not arriving?

Once your own sender is set up, these are the usual suspects, roughly in order:

• A typo in the SMTP details. The Auth logs show the error: a wrong password, port or host.
• The address is blocked by the email service. Addresses that bounced before end up on the service's suppression list and get skipped silently. Its logs show it.
• It's in spam. Usually a domain that isn't verified yet. Check the DNS records again.
• The email arrives, but the link opens localhost or the preview. That's the Site URL setting, a different problem with its own fix: see why apps break after going live, cause 2.
• A company email server holds it back. Some company firewalls quarantine password-reset emails. The user's IT team can let your domain through.

Keep it from coming back

Use a separate sender for login emails and for newsletters, so a marketing campaign can't hurt the delivery of password resets. And if bots start signing up with fake addresses, turn on CAPTCHA for sign-ups in Supabase: bounced emails are what get senders blocked.

Want it done for you?

Setting up the sender, the domain records and testing it all usually fits in one fix, from $170, and you pay only once emails arrive. See how it works.