Cómo personalizar correos de confirmación y recuperación de contraseña en Supabase Auth

Quien acaba de crear una cuenta necesita reconocer la aplicación y entender cómo confirmar el registro. Quien olvidó su contraseña necesita otro mensaje, con una acción igual de clara. Puedes diseñar ambos correos en Mailvex y transferir el HTML a las plantillas correspondientes de Supabase Auth.

Esta guía parte de una aplicación que utiliza un proyecto alojado de Supabase con confirmación de registro y recuperación de contraseña ya funcionando. Comprueba ambos flujos en el proyecto de pruebas antes del cambio. Utiliza SMTP personalizado configurado y plantillas procesadas desde el panel, sin un Send Email hook activo que controle la presentación. El objetivo es cambiar el diseño y conservar el comportamiento de autenticación existente.

1. Guarda lo que funciona antes de editar

En Authentication > Email Templates, abre Confirm sign up y guarda por separado Subject y todo el código de Body. Haz otra copia para Reset password. En cada fuente, registra la expresión exacta del href de la acción principal. Cópiala de la plantilla, nunca de un mensaje recibido: el enlace recibido puede contener un token real de un solo uso.

La ruta sencilla siguiente sirve cuando cada plantilla ya utiliza {{ .ConfirmationURL }}. Supabase proporciona la acción correspondiente a cada tipo de correo. Si el código utiliza un callback propio, SSR/PKCE, .TokenHash, OTP con .Token o condiciones Go, conserva su lógica y solicita revisión del desarrollador antes de adaptar el diseño. No sustituyas ese flujo por el predeterminado solo porque cambias la presentación.

Si hay un Send Email hook, su renderer controla los correos; no desactives un hook que funciona para seguir el tutorial. Las instalaciones locales o autogestionadas utilizan otra configuración. Si el editor es de solo lectura, revisa los requisitos de envío y acceso del proyecto, sin suponer que contratar Pro siempre sea la solución.

El SMTP integrado restringe los destinatarios al equipo y tiene límites bajos sujetos a cambios; no es la base de este ejemplo de producción. Confirma el SMTP personalizado en pruebas y utiliza cuentas y buzones bajo tu control. Si la recuperación ya falla, cambiar la plantilla no arregla el backend.

2. Crea dos mensajes, cada uno con una acción clara

En Mailvex, utiliza una cuenta con el correo confirmado y exportaciones disponibles. Selecciona Usar plantilla en el catálogo o Usar esta plantilla en los detalles. Prefiere una columna, logotipo opcional, título legible, texto breve y un botón principal. El mensaje debe seguir entendiéndose cuando las imágenes estén bloqueadas.

Confirmación de registro

Restablecimiento de contraseña

Mantén la segunda versión en un proyecto independiente, con la misma identidad visual y contenido propio. No incluyas campos para escribir contraseñas dentro del correo. El título y el preheader de Mailvex no modifican automáticamente Subject en Supabase: completarás ese campo en cada plantilla.

3. Prepara el enlace temporal y los elementos del diseño

Utiliza el bloque estándar Botón centrado y coloca la dirección siguiente únicamente en esa acción de autenticación. Es un marcador reservado que no funciona como destino; nunca publiques la versión final con esta dirección. No lo utilices en imágenes, enlaces de soporte ni otros elementos.

https://example.invalid/MAILVEX_AUTH_ACTION

• En el panel izquierdo, abre Ajustes > Etiquetas UTM y desactiva Añadir UTM a todos los enlaces.
• Después, vuelve a escribir la dirección temporal exacta en el botón, sin parámetros, fragmentos ni espacios. Desactivar UTM no elimina parámetros ya guardados en el enlace.
• En el botón y los bloques que lo contienen, abre Visibilidad y mantén desactivados Ocultar en móvil y Ocultar en escritorio. La acción debe aparecer en ambas pantallas.
• En el encabezado, abre Enlace «Ver en el navegador» y desactiva Mostrar enlace. Elimina también enlaces manuales a vistas previas alojadas que se hayan añadido al contenido.
• Elimina variables de demostración sin uso. En los bloques con Condición de visibilidad (ESP), desactiva Mostrar según condición cuando la regla no forme parte del diseño estático.
• Revisa preheader, pie, texto alternativo de imágenes y lectura en pantalla estrecha. Conserva la firma exigida por el plan.

La vista previa alojada en Mailvex no recibe la sustitución posterior de Supabase. Desactivar el enlace del encabezado no demuestra que se hayan eliminado versiones anteriores. En este proceso, el proyecto recibe solo el marcador: no pegues tokens ni enlaces reales de autenticación en el editor, capturas públicas o ejemplos compartidos.

Utiliza imágenes públicas que se abran sin iniciar sesión. El modo Mailvex conserva URLs alojadas; los archivos externos pueden permanecer en otros hosts. El modo Propio no sube los archivos a tu servidor. Mantén disponibles los recursos utilizados en mensajes que las personas todavía podrían abrir.

4. Exporta y adapta cada HTML por separado

Abre Exportar HTML y mantén mailvex en Formato de variables (ESP). Utiliza Copiar HTML una vez por variante: son dos proyectos y dos exportaciones diferentes. Descargar HTML es una alternativa, no otro paso obligatorio. Revisa tu cuota antes de repetir la operación.

Guarda el código completo en un archivo .html mediante un editor de texto o código. Conserva una copia exportada sin cambios y otra para adaptar. No separes body y CSS ni uses un editor de texto con formato que pueda modificar las comillas. Mailvex no conecta el proyecto con Supabase ni genera el token.

Para el flujo predeterminado ya confirmado en el respaldo de esa plantilla, busca la dirección temporal completa y sustituye todas sus coincidencias por esta expresión:

{{ .ConfirmationURL }}

El href resultante debe quedar así en el código fuente:

href="{{ .ConfirmationURL }}"

Un botón visible puede generar un href normal y otro en una representación VML para Outlook. La cantidad varía; por eso debes sustituir todas las coincidencias del marcador exclusivo, no solo la primera. No sustituyas todos los hrefs del documento: los destinos de soporte y las URLs de imágenes conservan su función.

El procesamiento de la plantilla puede eliminar comentarios condicionales y su versión VML, dejando el enlace HTML normal. La cantidad de hrefs puede disminuir después de renderizar. Utiliza el bloque estándar visible y comprueba la acción recibida; no elimines estilos globalmente ni supongas un aspecto idéntico en todos los clientes.

Busca MAILVEX_AUTH_ACTION en el archivo adaptado: no debe quedar ninguna coincidencia. Comprueba que los destinos usen la expresión aprobada, sin UTM, tracking ni llaves codificadas. Revisa también si el proveedor reescribe enlaces de Auth y configúralos sin seguimiento de clics. No construyas manualmente una URL de verificación ni copies una de un correo real.

5. Actualiza y prueba primero Confirm sign up

En el proyecto de pruebas, vuelve a Authentication > Email Templates > Confirm sign up. Completa Subject con el asunto de confirmación. Cambia Body a source y pega el HTML adaptado completo; revisa preview y utiliza Save changes. La vista previa ayuda a revisar el diseño, pero no comprueba una acción real ni el funcionamiento de la autenticación.

• Desde la aplicación existente, realiza un registro nuevo controlado con una dirección permitida. Para una cuenta de prueba todavía sin confirmar, usa la función de reenvío de confirmación ya implementada en la aplicación. Una invitación activa otro tipo de correo.
• En el correo nuevo, revisa texto, asunto, imágenes bloqueadas, lectura móvil y el botón en los clientes que utilizan tus usuarios.
• Abre la acción y comprueba el origen esperado de la aplicación y el estado de confirmación de la cuenta.
• Genera una solicitud nueva cuando necesites repetir. Respeta el navegador y el contexto exigidos por el flujo existente; no abras repetidamente un enlace antiguo de un solo uso.

Esta prueba envía un correo real. Comprueba primero su resultado antes de repetir solicitudes. Avanza a la otra plantilla después de validar la confirmación; así podrás identificar qué cambio produjo un posible problema.

6. Actualiza Reset password y completa la recuperación

Ahora abre Reset password. Utiliza su propio respaldo y comprueba de nuevo la expresión de la acción. Completa el Subject de restablecimiento, pega el HTML de la segunda variante y guarda con Save changes. Reutilizar el diseño no significa copiar la lógica de callback del registro a la recuperación.

• En la aplicación, inicia “Olvidé mi contraseña” para una cuenta de prueba existente que te pertenezca.
• Abre el correo recién recibido y sigue el botón hasta el formulario de nueva contraseña de la aplicación.
• Define la nueva contraseña en la aplicación y confirma que puedes iniciar sesión con ella. Abrir el enlace no completa el restablecimiento.
• Comprueba también asunto, texto, botón, imágenes y lectura en el celular para esta variante.

Una respuesta correcta al pedir recuperación no demuestra que se haya enviado a una dirección desconocida. Utiliza la cuenta existente adecuada. No expongas la contraseña, los códigos ni el enlace recibido en el artículo, registros compartidos o capturas. El resultado final debe ser un inicio de sesión correcto después del cambio.

Diagnóstico antes de cambiar producción

Si el cambio impide una acción que antes funcionaba, restaura Subject y Body anteriores únicamente de la plantilla afectada y vuelve a probar. Conserva la versión problemática para comparar. Evita modificar varias plantillas y la configuración de autenticación al mismo tiempo.

Identifica diseño, HTML y plantilla por separado

Guarda para cada tipo de correo el proyecto Mailvex, el HTML exportado, la versión adaptada y el respaldo de Supabase. En cada exportación nueva, repite la sustitución y las comprobaciones. El proyecto visual no actualiza una plantilla ya guardada en Supabase. Conserva las imágenes utilizadas y prueba el evento correspondiente después de cambios importantes.

Preguntas frecuentes

¿Mailvex envía el correo o crea la recuperación de contraseña?

No. Prepara el diseño y exporta HTML. Supabase y el servicio de envío configurado procesan el mensaje; la aplicación debe tener funcionando la autenticación y el formulario de nueva contraseña.

¿Por qué adaptar la expresión después de exportar?

Es un punto explícito de revisión entre diseño y autenticación, no una afirmación de que el editor rechace la expresión Go. Permite comprobar la acción aprobada y todos los destinos del botón antes de guardar la plantilla.

¿Esto vuelve multilingües los correos de la aplicación?

No automáticamente. Traducir el diseño o leer la guía en otro idioma no determina cómo tu aplicación selecciona el idioma del envío. Esa decisión depende de la implementación existente y requiere sus propias pruebas.