Los correos de autenticación de Supabase deben reflejar la identidad visual de tu producto sin alterar el proceso de acceso. El flujo más seguro parte de Migma: diseñas un correo sobrio y alineado con tu marca, validas su HTML y su aspecto en bandeja de entrada, y dejas que el equipo de desarrollo lo integre y lo pruebe en Supabase.
La parte crítica consiste en no romper el contrato técnico de autenticación. Un botón impecable no sirve de nada si una variable de plantilla se transforma en texto plano, si una herramienta de seguimiento reescribe el enlace o si el usuario acaba en un entorno incorrecto. Esta guía ofrece una lista de comprobación compartida entre diseño y desarrollo para evitar estos riesgos.
Este flujo de trabajo lo publica Migma. Prioriza la revisión visual, la legibilidad del diseño y una separación nítida entre maquetación y autenticación. No implica la existencia de un conector nativo entre Migma y Supabase ni sustituye los ajustes de seguridad de la plataforma. La información sobre el producto se contrastó con la documentación oficial el 14 de octubre de 2026.
Define con exactitud qué correo estás diseñando
Céntrate en una sola acción: confirmar el registro, aceptar una invitación, iniciar sesión, cambiar de dirección de correo, restablecer la contraseña o reautenticarse. Supabase documenta cada uno de estos casos como plantillas de autenticación independientes. Las notificaciones de seguridad forman otro grupo y deben habilitarse a nivel de proyecto.
Resume en una sola frase el objetivo de la plantilla. Para una confirmación de registro, podría ser: «Ayudar al usuario a verificar la dirección que acaba de introducir y devolverlo a la aplicación». Esta frase simplifica la fase de revisión: un banner promocional, un carrusel de novedades o una llamada a suscribirse a la newsletter no aportan nada a ese objetivo.
Antes de maquetar, define de común acuerdo el nombre de la aplicación, el canal de soporte, el remitente y el texto exacto del botón. El contenido debe describir la acción con rigor: un correo de confirmación no puede dar por hecho que la cuenta ya está verificada, igual que uno de recuperación no debe afirmar que la contraseña ya ha cambiado.
Crea un borrador de marca contenido en Migma
Revisa el logotipo, los colores, las tipografías y los datos oficiales importados de tu web en los ajustes de marca de Migma. A partir de ahí, plantea un correo de autenticación a una sola columna: logotipo reconocible, texto explicativo breve, una llamada a la acción principal y una vía de soporte.
Un encargo claro y directo sería:
Diseña un correo de confirmación de registro para nuestra aplicación. Mantén el nombre de producto y el texto de botón aprobados. Utiliza una sola columna, tipografía legible y una cabecera sobria. No modifiques las variables de autenticación. No añadas ofertas, enlaces con tracking, fechas límite ni afirmaciones no facilitadas.
Revisa el resultado visualmente. El texto útil debe ser texto real, nunca integrado dentro de una imagen grande. Comprueba cómo se comporta el mensaje cuando el cliente de correo bloquea las imágenes y asegúrate de que el producto sea identificable sin depender de fondos ilustrados.
Migma genera HTML optimizado para correo y permite realizar comprobaciones previas en bandeja de entrada. Esto resuelve la validación visual, pero no certifica que el flujo de autenticación funcione. Conviene separar siempre la aprobación del diseño de las pruebas funcionales de acceso.
Respeta las variables durante el traspaso a desarrollo
Usa los nombres oficiales de las variables de Supabase con total exactitud. La siguiente tabla sirve como referencia de trabajo, pero no sustituye la consulta de la documentación técnica de cada plantilla.
| Variable | Qué debe conservarse | Pregunta de revisión |
|---|---|---|
| `{{ .ConfirmationURL }}` | El enlace dinámico de confirmación | ¿La acción sigue utilizando la URL dinámica prevista? |
| `{{ .Token }}` | El código de un solo uso | ¿Es legible como texto y encaja con este flujo? |
| `{{ .SiteURL }}` | La dirección configurada para la aplicación | ¿Coincide con el entorno en el que se están haciendo las pruebas? |
| `{{ .RedirectTo }}` | El destino de redirección solicitado | ¿Se trata de un destino permitido y previsto? |
| `{{ .Data }}` | Los metadatos de usuario que emplea la plantilla | ¿Se gestiona bien el caso en el que falten metadatos? |
El motor de plantillas de Supabase se basa en Go templates. Su sintaxis es específica de este motor; no se puede intercambiar por etiquetas de combinación (merge tags) de otras plataformas de email. Evita sustituirlas durante la fase de diseño por fórmulas que parezcan equivalentes.
Conserva siempre el archivo original intacto para comparar el HTML exportado con él. Pide al equipo de desarrollo que examine la ortografía de las variables, los espacios, las llaves, la inserción en atributos de enlace y los bloques condicionales. Si una herramienta de diseño ha alterado alguna variable, corrígela y vuelve a probarla antes de cargar la plantilla en producción.
En las revisiones, utiliza siempre datos simulados. No incluyas tokens de acceso reales ni datos de cuentas de clientes en los documentos de diseño. Una previsualización con ejemplos permite comprobar cómo afectan al diseño los nombres largos o los campos vacíos sin comprometer la seguridad.
Elige la vía de integración adecuada
El flujo de exportación de Migma permite descargar el código HTML. Entrega ese archivo validado al equipo de desarrollo para que adapte e instale la plantilla en Supabase.
En proyectos alojados en Supabase (hosted), la documentación oficial remite a la sección de plantillas dentro del panel de control. En entornos de desarrollo local o configuraciones autoalojadas (self-hosted), la gestión se hace mediante archivos de configuración y plantillas HTML locales. Son rutas de despliegue distintas; modificar una no significa que la otra se haya actualizado.
Si el proyecto utiliza un hook de envío personalizado, desarrollo debe revisar también las entradas de ese hook, la plantilla configurada en el proveedor y su comportamiento en ejecución. No asumas que pegar el HTML en el panel de Supabase actualizará una plantilla gestionada por un proveedor externo. Deja documentado qué sistema genera realmente el correo.
Antes del despliegue, guarda una copia de la última versión operativa junto con la nueva. Incluye el tipo de mensaje y el entorno en el nombre del archivo para que cualquiera del equipo pueda restaurar una versión anterior sin margen de error.
Prueba el mensaje definitivo y la acción de acceso
Ejecuta Migma Email Preflight para verificar la maquetación, los textos, los enlaces y los riesgos habituales de entrega. Revisa el resultado en escritorio, móvil, modo claro y modo oscuro. Las URLs dinámicas de autenticación suelen requerir pruebas específicas en tiempo de ejecución, ya que su valor real solo se genera en el momento del envío.
A continuación, haz pruebas desde el entorno definitivo de Supabase con cuentas de control. Valida un alta desde cero, la redirección prevista, el comportamiento cuando falta un dato opcional (como el nombre) y la lectura en pantallas estrechas dentro de una bandeja de entrada real. En el caso de los correos de recuperación, completa todo el proceso de cambio de contraseña en lugar de limitarte a abrir el mensaje.
Supabase advierte sobre dos problemas habituales con los enlaces:
- Los filtros de seguridad de algunos clientes pueden rastrear y consumir URLs de confirmación de un solo uso antes de que el usuario haga clic.
- Los sistemas de seguimiento de clics externos pueden reescribir las URLs y romper los parámetros de autenticación.
La documentación recomienda recurrir a códigos de un solo uso (OTP) o a páginas intermedias de confirmación para el primer problema, y desactivar el seguimiento de clics en el proveedor para el segundo. El equipo técnico debe decidir qué solución corresponde a la aplicación; cambiar el estilo visual de un botón no soluciona ninguno de estos dos fallos.
Registra siempre las pruebas realizadas: versión de la plantilla, entorno, cliente de correo, acción comprobada, resultado y responsable. Que el proveedor acepte el envío no demuestra que el mensaje haya llegado a la bandeja de entrada ni que el usuario haya podido completar el registro.
Facilita las próximas iteraciones
Los futuros cambios de marca deben ser contenidos. Ajusta el logotipo, los espaciados o los textos aprobados sin alterar a la ligera la lógica de autenticación. Tras cada exportación, repite la comprobación de variables y el test en el entorno final.
Empieza por una sola plantilla en Migma, aprueba su diseño y haz el traspaso del HTML siguiendo esta lista de comprobación. Cuando ese primer correo funcione de extremo a extremo, traslada el mismo patrón visual al resto de correos de autenticación, validando cada flujo por separado.
Preguntas frecuentes
¿Es posible diseñar correos de autenticación de Supabase en Migma?
Sí. Puedes diseñar y validar la parte visual en Migma y luego exportar el HTML para que el equipo de desarrollo lo integre en la plantilla correspondiente de Supabase. Es un traspaso mediante HTML, no una integración nativa con Supabase.
¿Qué variables de plantilla es necesario conservar intactas?
Debes mantener exactamente las variables que utilice la plantilla seleccionada: enlaces de confirmación, tokens, URLs del sitio, destinos de redirección y metadatos. Confróntalas con la documentación oficial de Supabase y comprueba su valor en tiempo de ejecución.
¿Por qué puede fallar un enlace de confirmación tras recibir el correo?
Supabase advierte de que los filtros de seguridad pueden consumir enlaces de un solo uso mediante precargas automáticas (prefetch), y que las herramientas de seguimiento pueden reescribir las URLs. Revisa la configuración de autenticación y del proveedor; que un correo se envíe no garantiza que el inicio de sesión funcione.
¿Sustituye Migma Preflight a las pruebas de autenticación de Supabase?
No. Preflight sirve para revisar el diseño en bandeja de entrada, los textos, los enlaces y los riesgos habituales de entrega. Para validar que la acción de autenticación y la redirección funcionan de verdad, es imprescindible hacer pruebas controladas en el entorno final de Supabase.