Una app con Supabase necesita tres tipos de email: autenticación, eventos del producto y ciclo de vida. Compara qué tarea cubren Resend, Loops, Sequenzy y Brew.

Esta comparativa la publica Brew. Revisamos la documentación de producto enlazada el 28 de septiembre de 2026. Es un análisis de la documentación, no una afirmación de que hayamos probado a fondo cada plataforma. Consulta los límites actuales de los planes en la página de precios de cada proveedor.
Lanzas tu app con Supabase y se registran los primeros usuarios de fuera de tu equipo. Sus emails de confirmación siguen saliendo por el servicio de envío predeterminado, que solo entrega a direcciones autorizadas de antemano, así que no le llega a ninguno. El email de bienvenida que tenías pensado sigue siendo una nota en tu lista de tareas.
Una app con Supabase envía emails por tres motivos distintos. Los emails de autenticación incluyen la confirmación del registro, los magic links y los restablecimientos de contraseña. Los emails de eventos del producto se envían cuando ocurre algo en la base de datos. Las campañas de ciclo de vida cubren el onboarding, los recordatorios y la recuperación. Una misma herramienta puede cubrir más de una de estas tareas, pero Supabase aconseja mantener separados el correo de autenticación y el de marketing.
Esta guía clasifica Resend, Loops, Sequenzy y Brew según cuál de estas tareas documenta cada uno.
auth.users y emite eventos como auth.user.email_confirmed. Sequenzy sincroniza las filas de una tabla que tú eliges.| Tarea | Qué necesita | Herramientas que la documentan |
|---|---|---|
| Emails de autenticación | Un servidor SMTP o un hook de autenticación al que llame Supabase Auth | Resend, Loops, Sequenzy |
| Eventos del producto | Cambios en la base de datos convertidos en disparadores | Brew (auth.users), Sequenzy (una sola tabla, a elegir), Loops (sincronización de contactos) |
| Campañas de ciclo de vida | Secuencias, emails diseñados, audiencias | Brew, Loops, Sequenzy |
Revisamos la documentación de cada proveedor el 28 de septiembre de 2026.
La guía de SMTP de Supabase enumera los límites del servicio integrado. Solo envía a direcciones autorizadas de antemano. Su límite de envío es bajo, 2 mensajes por hora, y puede cambiar sin previo aviso. No tiene SLA de entrega. Supabase te pide que configures un SMTP personalizado para cualquier uso que vaya más allá de las pruebas y las demos.
La misma página desaconseja mezclar el correo de autenticación con el de marketing. Usa servicios distintos o, al menos, dominios de envío distintos, como auth.example.com y marketing.example.com, y no incluyas contenido promocional en los mensajes de autenticación.
La guía de Supabase de Resend es una configuración SMTP breve. Usas el host smtp.resend.com, el puerto 465, el usuario resend y tu clave de API como contraseña, y los introduces en la sección Authentication de Supabase. Necesitas un dominio verificado en Resend. A partir de ahí, Supabase Auth envía a través de Resend.
Loops documenta dos vías para Supabase. Un hook de autenticación (Auth Hook) envía todos los emails de Supabase Auth a través de Loops, y el SMTP queda como alternativa. Una sincronización de contactos aparte lleva los usuarios de Supabase a tu audiencia de Loops.
Sequenzy puede enviar los emails de Supabase Auth a través de su servicio SMTP. Configura plantillas transaccionales predeterminadas para restablecer contraseñas, magic links, invitaciones y notificaciones de seguridad, o puedes introducir las credenciales SMTP manualmente.
La integración de Brew con Supabase no envía los emails de Supabase Auth, y Brew no documenta ningún relay SMTP. Deja los emails de verificación, de magic link y de restablecimiento en un proveedor SMTP. La API de Brew puede enviar emails transaccionales que active tu app, como un recibo. Los mensajes propios de Supabase Auth siguen necesitando SMTP o un hook de autenticación.
La integración de Brew con Supabase ejecuta un script de configuración que instala un trigger de base de datos en auth.users. El trigger firma cada cambio con pgcrypto, lo envía con pg_net a un webhook de Brew exclusivo y guarda el secreto compartido en Supabase Vault. Brew recibe tres eventos sin procesar: auth.user.created, auth.user.updated y auth.user.deleted. Además, deriva otros nueve a partir de los cambios en las columnas:
auth.user.email_confirmed y auth.user.phone_confirmedauth.user.email_changed y auth.user.password_changedauth.user.signed_inauth.user.banned y auth.user.unbannedauth.user.invitedauth.user.upgraded_from_anonymousLos usuarios se sincronizan como contactos con campos supabase_*, como el estado de la cuenta, la fecha de verificación del email y el último inicio de sesión. La documentación de Brew advierte que las renovaciones del token también actualizan last_sign_in_at, así que auth.user.signed_in no es, por sí solo, una señal fiable de que el usuario “ha vuelto”.
Para eventos de fuera de auth.users, como project_created o invite_sent, crea un disparador personalizado en Brew y actívalo desde una Edge Function de Supabase. La guía de Lovable de Brew muestra ese patrón. La función lee BREW_API_KEY de los secretos de Supabase y llama a POST /v1/automations/triggers/{triggerEventId}/fire.
Sequenzy se conecta a Supabase con OAuth y vigila una tabla que tú eliges, normalmente public.profiles, mediante un trigger de pg_net. Detecta automáticamente las columnas de email, ID de usuario y nombre, y sincroniza las demás columnas para segmentar. Las inserciones emiten contact.subscribed. Las actualizaciones refrescan los atributos sin emitir ningún evento, y las eliminaciones emiten contact.unsubscribed. Solo una tabla por integración usa webhooks automáticos.
Loops sincroniza los usuarios de Supabase con tu audiencia y puede iniciar flujos de trabajo a partir de esos datos. La sincronización de contactos se configura por separado de la vía de los emails de autenticación.
Brew genera emails a partir del email-design.md de tu marca, crea automatizaciones a partir de un prompt y envía desde tu dominio verificado. Un flujo de bienvenida puede empezar con auth.user.email_confirmed, para que el primer email llegue solo a quienes ya han verificado su dirección. Brew no tiene canal de SMS y no se encarga de los emails de Supabase Auth.
Loops y Sequenzy cubren tanto las campañas de ciclo de vida como los emails de autenticación, así que un solo proveedor puede encargarse de ambas cosas. Si optas por esa vía, usa igualmente dominios de envío distintos para la autenticación y el marketing, como aconseja Supabase.
Este es un posible reparto. No lo hemos probado de principio a fin.
auth.example.com.auth.users. Una automatización de bienvenida empieza con auth.user.email_confirmed.project_reminder_eligible. Una automatización publicada envía el recordatorio a partir de ese evento. Otra opción es definir y sincronizar en Brew un campo de contacto booleano, has_project, y comprobar contact.has_project equals false después de una espera. Esa condición lee el valor actual del campo del contacto en Brew; el payload del evento original no cambia.Según Supabase, no. El servicio predeterminado solo envía a direcciones autorizadas de antemano, con un límite bajo, y no tiene SLA. Configura un SMTP personalizado.
No. La integración de Brew con Supabase inicia automatizaciones a partir de los cambios en auth.users. Los emails de verificación y de restablecimiento necesitan un proveedor SMTP o un hook de autenticación.
email_confirmed antes de enviar el email de bienvenida?Así, la bienvenida solo llega a direcciones que funcionan, y llega después del email de verificación en lugar de a la vez.
No de forma automática. La documentación de Brew indica que todos los destinatarios de marketing deben haber dado su consentimiento antes de importarlos. Guarda el consentimiento en el momento del registro y filtra por él.
Para ver qué eventos llegan desde tu proyecto, conecta Supabase en Brew, inserta un usuario de prueba y observa el panel Eventos recientes antes de publicar un flujo.
