Supabase "email rate limit exceeded"? Turn on custom SMTP, then raise the limit
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
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
-
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. -
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. - 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
- Read the error code returned by the sign-up or reset call.
over_email_send_rate_limitandemail_address_not_authorizedneed different fixes. - In the Supabase dashboard, open Authentication > SMTP settings and check whether custom SMTP is enabled.
- Open Authentication > Rate Limits and read the limit for emails sent.
Fix 1: connect a real email provider
- Create an SMTP account with a transactional email provider and verify your sending domain there.
- In Authentication > SMTP settings, enter the host, port, username, password, a From address such as
[email protected], and a sender name. - 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.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.