Supabase email rate limit exceeded: cómo quitar el límite

“Email rate limit exceeded” en Supabase significa que tu proyecto llegó al máximo de correos de autenticación permitidos por hora. Si usas el correo incluido de Supabase, el límite es muy bajo: según su documentación de rate limits, a noviembre de 2026 son 2 correos por hora por proyecto. La solución es configurar un SMTP propio y después subir el límite en Authentication → Rate Limits.

Por qué aparece tan rápido

Cada registro, cada “olvidé mi contraseña”, cada magic link y cada reenvío de confirmación cuenta como un correo. Con un límite de 2 por hora, basta con que tú hagas dos pruebas para que el tercer usuario vea el error (código HTTP 429, “demasiadas peticiones”; en los códigos de Supabase aparece como over_email_send_rate_limit).

Además, el servicio incluido solo entrega a miembros de tu organización en Supabase. Está pensado para probar, no para usuarios reales.

Solución: SMTP propio + ajustar el límite

1. Configura SMTP propio

1. Crea cuenta en un proveedor de correo transaccional. La guía de SMTP de Supabase menciona Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail y Brevo.
2. Verifica tu dominio en el proveedor (registros DNS SPF y DKIM).
3. En Supabase: Authentication → configuración de SMTP → activa Custom SMTP.
4. Llena host, puerto (587 o 465), usuario, contraseña y remitente ([email protected]).
5. Guarda.

Supabase indica que, al activar SMTP propio, el límite inicial queda en 30 mensajes por hora.

2. Sube el límite

1. Ve a Authentication → Rate Limits.
2. Ajusta el límite de correos enviados por hora al volumen que esperas.
3. Guarda.

También se puede cambiar con la API de administración de Supabase (campo rate_limit_email_sent):

curl -X PATCH "https://api.supabase.com/v1/projects/TU_PROJECT_REF/config/auth" \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"rate_limit_email_sent": 100}'

El token de acceso es personal y da control sobre tus proyectos: nunca lo pongas en el código de tu app.

3. Revisa también el límite de tu proveedor

Tu proveedor SMTP tiene su propio límite según tu plan. Si Supabase permite 100 por hora pero tu plan del proveedor permite menos, fallará igual. Revisa su panel.

Otros límites que se confunden con este

Mensaje	Qué es	Qué hacer
email rate limit exceeded	Límite de correos del proyecto por hora	SMTP propio y subir el límite
“For security purposes, you can only request this once every 60 seconds”	Límite por usuario para reenvíos	Esperar; muestra un contador en tu app
Email address not authorized	El correo incluido solo envía a tu equipo	SMTP propio
over_request_rate_limit	Demasiadas peticiones desde la misma IP	Revisar que tu app no haga peticiones en bucle

Los códigos están en la lista de errores de Auth de Supabase.

Cómo evitar que tu propia app gaste el límite

1. Botón de “reenviar correo” con espera. Desactívalo 60 segundos después de cada clic.
2. No reenvíes automáticamente en cada carga de página.
3. Valida el correo antes de enviar (formato correcto) para no gastar envíos en errores de dedo.
4. Usa un proyecto separado para pruebas o desactiva la confirmación solo en el proyecto de desarrollo, nunca en producción.

// Ejemplo: deshabilitar el botón de reenvío 60 s
const [espera, setEspera] = useState(0);

async function reenviar() {
  await supabase.auth.resend({ type: "signup", email });
  setEspera(60);
  const t = setInterval(() => {
    setEspera((s) => {
      if (s <= 1) clearInterval(t);
      return s - 1;
    });
  }, 1000);
}
// <button disabled={espera > 0} onClick={reenviar}>Reenviar {espera > 0 && `(${espera})`}</button>

Cómo comprobar que ya quedó

Después de configurar SMTP y subir el límite, no lo des por hecho con una sola prueba:

1. Regístrate con un correo que no sea miembro de tu organización en Supabase (por ejemplo, una cuenta personal de Gmail). Si llega, el SMTP propio está funcionando; con el correo incluido no habría llegado.
2. Revisa la carpeta de spam. Si cae ahí, falta terminar la verificación del dominio (SPF, DKIM y, de preferencia, DMARC).
3. En Supabase abre los logs de Auth y busca el intento de envío. Un error de autenticación SMTP ahí suele significar usuario o contraseña equivocados, o puerto incorrecto.
4. En el panel de tu proveedor de correo, confirma que el mensaje aparece como enviado o entregado.

Cómo elegir proveedor SMTP

Para correos de autenticación de una app pequeña, casi cualquiera de los proveedores que menciona Supabase funciona. Lo que conviene comparar:

• Volumen incluido en su plan gratuito o de entrada, y qué pasa al rebasarlo (si deja de enviar o te cobra). Consulta la página de precios de cada uno; cambian seguido.
• Facilidad para verificar tu dominio: algunos te dan los registros DNS listos para copiar.
• Registros de entrega: poder ver si un correo rebotó o cayó en spam ahorra mucho tiempo de soporte.
• Si ya usas uno: si tu empresa ya manda correos con AWS o con otro servicio, reutilízalo en vez de abrir otra cuenta.

Evita usar tu cuenta personal de Gmail u Outlook como SMTP: tienen límites diarios pensados para personas, no para apps, y los correos de una app desde una cuenta personal se marcan como sospechosos con facilidad.

Si tu app la hiciste con Lovable o Bolt

Si conectaste tu propio proyecto de Supabase, los pasos son exactamente los de arriba, en el panel de Supabase. Si tu app usa la nube integrada de la herramienta (por ejemplo, Lovable Cloud), la configuración de correo de autenticación puede estar en el panel de esa herramienta y no en Supabase; revisa su documentación. En cualquier caso, no le pidas al chat de la IA que “quite el límite”: el límite no está en tu código, está en la configuración del servicio, y el agente puede terminar desactivando la confirmación de correo, lo cual abre la puerta a registros falsos.

Otra forma de enviar menos correos es ofrecer inicio de sesión con Google u otro proveedor: esos usuarios no necesitan correo de confirmación.

Errores comunes

• Hacer pruebas con muchos registros seguidos en el proyecto de producción.
• Configurar SMTP pero no verificar el dominio: el proveedor rechaza y parece que sigue el límite.
• Subir el límite en Supabase sin revisar el del proveedor.
• Confundir este error con el de 60 segundos y cambiar la configuración equivocada.

Si los correos tampoco salen después de configurar SMTP, sigue con supabase error sending confirmation email. Si tu app es de Lovable, mira también Lovable error verifying email. Y si prefieres dejarlo bien configurado de una vez, en Black Engine lo revisamos contigo por WhatsApp.