Supabase stopped sending sign-up emails? Fix over_email_send_rate_limit with custom SMTP

The first few test sign-ups go through. Then the confirmation emails stop, password resets never arrive, and the auth call returns something like:

email rate limit exceeded
over_email_send_rate_limit
429 Too Many Requests
email_address_not_authorized

Nothing is wrong with your code. The project is still on Supabase's built-in email provider, which sends at most 2 emails an hour for the whole project and only to people on your project team. The fix is to plug in your own SMTP provider and then set the hourly limit to match real traffic.

Three different causes behind the same symptom

• Built-in sender still active. Addresses outside the team are refused with email_address_not_authorized, and the 2-per-hour budget is shared by sign-ups, resets, magic links and invites. Supabase calls this service best effort and not meant for production.
• One address asked too often. Repeated attempts for the same person trigger over_email_send_rate_limit (HTTP 429). By default a user waits 60 seconds between confirmation or reset emails.
• New SMTP setup, starting limit. Once custom SMTP is on, Supabase begins at 30 emails an hour to protect the new sender's reputation. That stays until you raise it.

Work out which one you have

Look at the error code the sign-up or reset request returned; the two codes point to different fixes. Then, in the dashboard, check Authentication > SMTP settings (is custom SMTP enabled?) and Authentication > Rate Limits (what is the limit for emails sent?).

Step 1: send through your own provider

Sign up with a transactional email provider and verify your sending domain with them. In Authentication > SMTP settings, fill in the host, port, username and password, a From address like no-reply@yourdomain.com, and a sender name. After you save, Supabase can email any address, not just your team.

Step 2: set a limit that fits your busiest hour

In Authentication > Rate Limits, set the emails-sent limit high enough for your peak hour of sign-ups and resets. If you'd rather script it, the Management API reads and updates the same setting:

# 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> }'

Leave the per-user wait in place so nobody can flood their own inbox.

Test it

Sign up with an address that isn't on your team and confirm the email arrives from your domain. Then request three password resets within an hour from different addresses; all three should land.

Keep it fixed

Move to custom SMTP before any real users are invited, and add SPF, DKIM and DMARC records for the sending domain so the emails reach inboxes instead of spam. This applies to every auth email: one-time codes, magic links and invites use the same sender.

Docs: Supabase rate limits, custom SMTP and Auth error codes.

The original guide is on our site: Supabase "email rate limit exceeded": the fix. Before launch, the free Launch Check checks a live app for exposed keys, missing security headers and broken basics.