Los detalles siguientes provienen de la documentación de Supabase del 23 de octubre de 2026. Consúltala para ver los límites y ajustes actuales. Para lo básico, como enviar tus primeros correos de prueba y configurar un remitente, empieza con Probar correos de Supabase Auth.
El correo nunca llega
El remitente integrado no enviará correos a tus testers. El servicio de correo propio de Supabase solo entrega a miembros del equipo de tu proyecto, con un máximo de 2 correos por hora. Te funciona a ti porque estás en el equipo, y luego rechaza a todos los demás con “Email address not authorized”. Configura SMTP personalizado en Authentication, Emails.
Tu proveedor de SMTP sigue en su sandbox. Una cuenta nueva de Resend solo envía a tu propia dirección hasta que verifiques un dominio, y Amazon SES solo a direcciones que hayas verificado. Supabase entrega el correo y el proveedor lo descarta sin avisar.
Volviste a pedirlo demasiado pronto. De forma predeterminada, cada usuario puede recibir un correo de confirmación, enlace mágico, código o restablecimiento cada 60 segundos, y cada dirección IP puede hacer 30 solicitudes de registro e inicio de sesión cada 5 minutos. Una prueba que reintenta rápido, o una suite que se ejecuta desde una sola máquina de CI, alcanza estos límites y recibe un 429. Auméntalos para tu proyecto de staging en Authentication, Rate Limits.
La dirección ya tiene una cuenta. Para no revelar quién se ha registrado, Supabase responde a un registro con una dirección confirmada como si hubiera funcionado, con un usuario sin identidades, y no envía ningún correo. Una prueba que reutiliza una dirección espera un correo que nunca llega. Usa una dirección nueva en cada ejecución.
Confirm email está desactivado. En ese caso, el registro inicia la sesión del usuario de inmediato y no envía nada. Revisa Authentication, Sign In / Providers, Email. A menudo se desactiva durante el desarrollo y nunca se vuelve a activar.
El enlace dice que no es válido o que caducó
Haces clic en el enlace y llegas a tu app con error_code=otp_expired (“Email link is invalid or has expired”) en la barra de direcciones.
- Ya se usó. Los enlaces funcionan una vez y duran una hora de forma predeterminada. Pedir otro correo reemplaza el enlace anterior, así que usa el más reciente.
- Un escáner lo abrió primero. Algunos servicios de correo, y herramientas de seguridad corporativas como los escáneres de enlaces, abren cada enlace de un correo nuevo para revisarlo. Eso consume un enlace de un solo uso antes de que la persona haga clic. Supabase sugiere enviar un código de 6 dígitos en su lugar (
{{ .Token }}en la plantilla) o enlazar a una página propia donde la persona presione un botón para confirmar. Proxy Mail QA nunca abre enlaces, así que si un enlace funciona en tu prueba pero falla para usuarios reales, la causa probable es un escáner.
El enlace se abre, pero nadie queda con la sesión iniciada
Se abrió en otro navegador. Con el flujo PKCE, que usan los helpers del lado del servidor de Supabase, el navegador que inició el registro guarda un secreto que el enlace necesita. Si abres el enlace en otro navegador, una ventana privada u otro dispositivo, el intercambio falla, a menudo con “both auth code and code verifier should be non-empty”. Los testers deben abrir el enlace en el navegador con el que se registraron. Para enlaces que funcionen en cualquier lugar, créalos a partir de {{ .TokenHash }} y verifícalos en tu servidor con verifyOtp.
Nada completa el inicio de sesión. El enlace llega a tu app con un code (o un token) en la dirección, y alguna página tiene que intercambiarlo por una sesión. Si falta esa ruta, la persona ve tu página de inicio sin la sesión iniciada. Comprueba que la página de destino del enlace llame a exchangeCodeForSession, o a verifyOtp con el hash del token.
El servidor no puede ver la sesión. El enlace predeterminado pone la sesión después de un # en la dirección, que solo el navegador puede leer. Las apps renderizadas en el servidor necesitan el enlace con hash del token indicado arriba.
Los enlaces llevan a localhost o al entorno equivocado
La Site URL empieza como http://localhost:3000, y cualquier redirectTo que no esté en la lista de Redirect URLs recurre a ella. Configura la Site URL con la app desplegada y agrega cada entorno a la lista. Más información en por qué los correos enlazan a localhost; Proxy Mail QA marca esos enlaces en la fila de la dirección.
El registro falla con “Database error saving new user”
Algo en la base de datos rechazó al nuevo usuario, casi siempre un trigger en auth.users, como uno que crea una fila en profiles. Causas comunes: la tabla o una columna en la que escribe no existe, la función no es security definer y por eso no puede escribir en public, o una columna que rellena es not null y el registro no la envió. Los registros de Auth y Postgres de Supabase muestran el error real.
Prueba también con valores incómodos: un nombre con apóstrofo, otro sistema de escritura o 255 caracteres pueden romper una columna del perfil que los datos de prueba normales nunca alcanzan. Nombres y contraseñas inusuales tiene una lista para probar.
El correo de restablecimiento llega, pero la contraseña no cambia
Un enlace de restablecimiento inicia la sesión de la persona con una sesión de recuperación y dispara el evento PASSWORD_RECOVERY. Tu app tiene que detectarlo, mostrar un formulario para la nueva contraseña y llamar a updateUser con ella. Si no lo hace, la persona simplemente queda con la sesión iniciada y con su contraseña anterior. Con PKCE, el enlace también debe abrirse en el navegador que lo pidió. Más información en Probar correos de restablecimiento de contraseña.
El captcha bloquea tus pruebas automatizadas
Con la protección de captcha activada (Authentication, Attack Protection), cada registro e inicio de sesión necesita un token de captcha, así que un navegador automatizado no puede pasar. En tu proyecto de staging, usa las claves de prueba de tu proveedor de captcha, que siempre pasan, y reserva las claves reales para producción.
Funciona en Supabase local, pero no en el proyecto alojado
La CLI de Supabase captura el correo local en su propio visor de correo (normalmente en localhost:54324) y lee las plantillas de supabase/config.toml. El proyecto alojado usa las plantillas, el remitente y los límites de frecuencia del panel. Prueba en un proyecto de staging alojado antes del lanzamiento, con correo real a una dirección que lo reciba.
Compruébalos todos de una vez
- Crea una dirección de Proxy Mail QA nueva para cada escenario: usuario nuevo, usuario existente, restablecimiento de contraseña, enlace mágico.
- Recorre el flujo en tu app. El código o enlace aparece en la fila de la dirección en segundos.
- Mira la fila: un enlace a localhost aparece marcado, y la bandeja de entrada muestra si el correo indica cuándo caduca su enlace.
- Abre el enlace en el mismo navegador con el que te registraste y comprueba que la sesión se inició en el sitio correcto.
¿Lo creaste con Lovable, Bolt o v0? Problemas de registro e inicio de sesión en apps hechas con vibe coding cubre lo que esas apps suelen hacer mal además de esto.