Sign-ups worked yesterday. Today new users never get the confirmation email, and the sign-up or reset call comes back with one of these:

email rate limit exceeded over_email_send_rate_limit 429 Too Many Requests Email address not authorized email_address_not_authorized

Supabase's built-in email provider sends at most 2 emails an hour for the whole project, and only to members of your team. Connect your own SMTP provider and Supabase sends to every address, starting at 30 emails an hour, which you can raise.

I see this a lot in Lovable and Bolt apps on Supabase right when the first real users arrive.

Why it happens

  1. The default email service is still on. It refuses addresses outside the project team (email_address_not_authorized) and sends 2 emails an hour for the whole project, across every sign-up, reset, magic link and invite. Supabase describes it as best effort and not meant for production.
  2. Too many emails to one address. Repeated sign-up or reset attempts trip over_email_send_rate_limit (HTTP 429) for that address. By default the same user waits 60 seconds before another confirmation or reset email.
  3. The custom SMTP limit is still the starting value. After you add custom SMTP, Supabase starts at 30 emails an hour to protect your new sender's reputation, until you change it.

Find the cause

  1. Read the error code returned by the sign-up or reset call. over_email_send_rate_limit and email_address_not_authorized need different fixes.
  2. In the Supabase dashboard, open Authentication > SMTP settings and check whether custom SMTP is enabled.
  3. Open Authentication > Rate Limits and read the limit for emails sent.

Fix 1: connect a real email provider

  1. Create an SMTP account with a transactional email provider and verify your sending domain there.
  2. In Authentication > SMTP settings, enter the host, port, username, password, a From address such as no-reply@yourdomain.com, and a sender name.
  3. Save. From then on, Supabase sends auth emails to every address, not only your team.

Fix 2: raise the limit to fit real traffic

Set the limit for emails sent in Authentication > Rate Limits to cover your busiest hour of sign-ups and resets. Or do it from a script with the Management API:

# Access token from https://supabase.com/dashboard/account/tokens export SUPABASE_ACCESS_TOKEN="your-access-token" export PROJECT_REF="your-project-ref" # Read the current limit curl -X GET "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \ -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" | jq '.rate_limit_email_sent' # Set it to your busiest hour of auth emails (replace <emails-per-hour>) curl -X PATCH "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \ -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "rate_limit_email_sent": <emails-per-hour> }'

Keep the per-user wait between emails, so one person can't flood their own inbox.

Check the fix worked

  • Sign up with an address outside your team: the confirmation arrives from your domain.
  • Request three password resets in an hour from different addresses: all of them arrive.

Stop it coming back

  • Switch to custom SMTP before you invite any real users.
  • Add the sending domain's SPF, DKIM and DMARC records at your provider so the emails reach inboxes.

Quick answers

Is the built-in service fine for launch? No. Supabase describes it as best effort, for testing and non-critical projects, with no delivery guarantee.

Does this affect magic links and invites too? Yes. Every auth email, including one-time codes, magic links and invites, goes through the same sender.

Sources: Supabase rate limits, Send emails with custom SMTP, Auth error codes.

Full write-up with the same steps: Supabase "email rate limit exceeded": the fix. Before launch, the free Launch Check looks over your live app for exposed keys, missing security headers and broken basics.

I wrote this with AI assistance and reviewed it myself.