Saltar al contenido principal
Para personalizar las plantillas de correo electrónico, debes configurar un proveedor externo de correo electrónico SMTP. Las plantillas de correo electrónico no están disponibles si usas el proveedor de correo electrónico integrado de Auth0.

Personalizar las plantillas de correo electrónico

Para personalizar una plantilla de correo electrónico:
  1. Ve a Dashboard > Marca > Plantillas de correo electrónico.
  2. En el menú desplegable Plantilla, selecciona la plantilla de correo electrónico que quieres actualizar.
  3. En la página de la plantilla de correo electrónico, actualiza los campos que quieras personalizar. Los campos Dirección del remitente, Asunto, Redirect To y Mensaje admiten la sintaxis Liquid. Para obtener más información, consulta Sintaxis de Liquid admitida.
  4. Haz clic en Guardar para guardar los cambios, en Probar para probarlos o en Restablecer para revertirlos.

Dirección del remitente

El campo Dirección del remitente establece la dirección de correo electrónico que los usuarios ven como remitente cuando reciben un correo de Auth0. Si no se configura, los correos usan la dirección de correo electrónico del campo From configurado en tu proveedor de correo electrónico. Al configurar el campo Dirección del remitente, para permitir que Auth0 envíe correos firmados digitalmente en tu nombre, debes configurar dos formas de autenticación de correo electrónico: Sin SPF y DKIM configurados, es posible que los correos no se entreguen, que los filtros de spam los bloqueen o que muestren “On Behalf Of” y revelen el remitente (tu proveedor de correo electrónico) además de la dirección del remitente. Para configurar SPF y DKIM, debes crear registros TXT para tu dominio. Los valores de los registros TXT y otros detalles del proceso varían, así que sigue las instrucciones de tu proveedor de correo electrónico para esta configuración. En general, el registro TXT para SPF debe tener el nombre de host establecido en @ o vacío, y el valor en v=spf1 include:<YOUR_PROVIDER_SPF_DOMAIN> -all. El registro TXT para DKIM debe tener el nombre de host establecido en el dominio que usas para enviar correos y el valor establecido en la firma DKIM que generas con tu proveedor.

Asunto

El campo Asunto define el asunto del correo electrónico. Si no se configura, Auth0 lo completa automáticamente según el tipo de correo electrónico.

Mensaje

El campo Mensaje define el contenido HTML del cuerpo del mensaje. Cada plantilla incluye un cuerpo de mensaje predeterminado que puedes modificar o descartar por completo para escribir el tuyo propio.

Vigencia de la URL y Redirect To

Las plantillas de correo electrónico que incluyen un enlace (Verification Email (Link), Change Password (Link) y Blocked Account Email) tienen dos campos adicionales para gestionar estos enlaces:
  • El campo URL lifetime establece durante cuánto tiempo un enlace sigue siendo válido antes de expirar. De forma predeterminada, la vigencia es de 432.000 segundos (cinco días).
  • El campo Redirect To establece una URL a la que se redirige al usuario después de completar la acción desde un enlace incluido.
Actualmente, Universal Login ignora el valor del campo Redirect To en la plantilla Password Reset y, en su lugar, redirige a la ruta de inicio de sesión predeterminada o a una página de error.Para personalizar la URL de Redirect To para el restablecimiento de contraseña al usar Universal Login, use api.transaction.setResultURL() del trigger post-challenge de Actions
Se agregan dos parámetros de consulta a la URL de Redirect To:
  • success, establecido en true o false, que indica si la acción se completó correctamente
  • message, establecido en una descripción adicional del resultado, como “El acceso expiró.” o “Se verificó tu correo electrónico. Ya puedes seguir usando la aplicación.”
Si tiene problemas con la ubicación de los parámetros de consulta en las URL de Redirect To para aplicaciones de una sola página (SPA), la siguiente solución alternativa puede ayudar.
RFC 3986 define el orden esperado de una URL como scheme|authority|path|query|fragment. Sin embargo, los frameworks de SPA (como Angular) suelen esperar URL con el formato scheme|authority|path|fragment|query, en el que la consulta va después del fragmento.Esto puede causar problemas con la ubicación de los parámetros de consulta en las URL de Redirect To. Si la URL de Redirect To de su SPA es http://localhost:3000/#/register, se redirige al usuario a http://localhost:3000/?exampleParameter=exampleValue#/register en lugar de a http://localhost:3000/#/register?exampleParameter=exampleValue.Para solucionar esta limitación de los frameworks de SPA, puede hacer lo siguiente:
  1. Agregar una URL del lado del servidor como URL de Redirect To con un parámetro route que registre la ruta de la SPA para la redirección. Por ejemplo, http://localhost:3000/register?route=register.
  2. Crear un controlador de rutas del lado del servidor que lea route y otros parámetros de la URL, redirija a la ruta de la SPA especificada en el parámetro route y agregue los demás parámetros recibidos de Auth0. Por ejemplo:
    var express = require('express');
    var router = express.Router();
    // Para leer parámetros de la cadena de consulta y convertirlos en cadena:
    var qs = require('qs');
    
    router.get('/register', function(req, res, next) {
        // Recupera el parámetro route que contiene la ruta
        // del lado del cliente de la SPA a la que se debe redirigir al usuario.
        var route = req.query.route;
    
        // Elimina route de los parámetros de consulta.
        delete req.query.route;
    
        // Envía una redirección 302 a la ruta esperada.
        res.redirect('http://localhost:3000/#/' + route + '?' +  qs.stringify(req.query));
    });
    
    module.exports = router;
    

Probar las plantillas actualizadas

Para probarlas, haga clic en Try, introduzca una dirección de correo electrónico válida a la que pueda acceder y elija el tipo de conexión correcto. Auth0 envía el correo electrónico para una aplicación predeterminada que comparte el nombre de su inquilino (no el nombre descriptivo de su inquilino). Para probar plantillas para distintas aplicaciones, cree un usuario de ejemplo para completar los flujos correspondientes. Puede activar manualmente correos electrónicos de verificación para aplicaciones y usuarios específicos mediante el endpoint Send an email address verification email de la Management API.

Ejemplos de casos de uso de personalización

La personalización de las plantillas de correo electrónico permite muchos casos de uso. Por ejemplo:
Puede configurar distintas URL de Redirect To según el nombre de su aplicación. Por ejemplo:
{% if application.name == 'JWT.io' %}
    https://jwt.io
{% else %}
    https://auth0.com
{% endif %}
Como el nombre de la aplicación se codifica por seguridad, use un valor codificado (especialmente si el nombre de su aplicación contiene algún carácter que cambia al codificarse). Por ejemplo, use My%20App en lugar de My App.
Con Liquid, puede usar el parámetro request_language para obtener la configuración de idioma a partir del valor del encabezado o, en su defecto, usar la configuración de idioma del navegador del usuario.Por ejemplo:
{% assign language = request_language %}
  {% if language %}
    {% assign language = request_language | slice: 0,2 %}
  {% endif %}
{% if language == 'es' %}
  Cuenta de Example: bloqueada
{% elsif language == 'de' %}
  Ihr Example wurde gesperrt
{% elsif language == 'fr' %}
  Compte Example bloqué
{% elsif language == 'ja' %}
  Example アカウントがブロックされました
{% elsif language == 'pt' %}
  Conta da Example bloqueada
{% elsif language == 'zh' %}
  Example 帐户被阻止
{% else %}
  Example account blocked
{% endif %}
También puede usar la propiedad user_metadata.lang para adaptar el contenido según el idioma preferido del usuario. Por ejemplo, puede usar una Action para establecer la propiedad user_metadata.lang y luego leer el parámetro user_metadata.lang en sus plantillas de correo electrónico para enviar mensajes en el idioma adecuado.
Para tener un control más detallado, puede enviar correos electrónicos fuera de los flujos de trabajo estándar y crear tickets (URL generadas para acciones de flujos de correo electrónico, como restablecimientos de contraseña) mediante la Management API. Los endpoints de correo electrónico y tickets de la Management API tienen parámetros adicionales que le permiten personalizar su comportamiento. Para obtener más información, consulte Personalice el manejo de correos electrónicos y tickets con la Management API.