Personnaliser les modèles de courriel

Pour personnaliser les modèles de courriel, vous devez configurer un fournisseur de courriel SMTP externe. Les modèles de courriel ne sont pas offerts lorsque vous utilisez le fournisseur de courriel intégré d’Auth0.

Personnaliser les modèles de courriel

Pour personnaliser un modèle de courriel :

Accédez à Dashboard > Branding > Email Templates.
Dans la liste déroulante Template, sélectionnez le modèle de courriel que vous souhaitez mettre à jour.
Sur la page du modèle de courriel, mettez à jour les champs que vous souhaitez personnaliser. Les champs Adresse d’expéditeur, Objet, Redirect To et Message prennent en charge Liquid. Pour en savoir plus, consultez la syntaxe Liquid prise en charge.
Cliquez sur Save pour enregistrer vos modifications, sur Try pour les tester, ou sur Reset pour rétablir la version précédente de vos modifications.

Adresse d’expéditeur

Le champ Adresse d’expéditeur définit l’adresse courriel que les utilisateurs voient comme expéditeur lorsqu’ils reçoivent un courriel d’Auth0. S’il n’est pas défini, les courriels utilisent l’adresse courriel du champ De configuré pour votre fournisseur de services de courriel. Lorsque vous définissez le champ Adresse d’expéditeur, pour permettre à Auth0 d’envoyer en votre nom des courriels signés numériquement, vous devez configurer deux mécanismes d’authentification des courriels :

Sender Policy Framework (SPF), qui autorise des adresses IP précises à envoyer des courriels à partir d’un domaine
DomainKeys Identified Mail (DKIM), qui signe les courriels de façon cryptographique afin que les serveurs de messagerie puissent vérifier qu’ils proviennent bien du domaine indiqué

Sans configuration de SPF et de DKIM, les courriels pourraient ne pas être livrés, être bloqués par des filtres antipourriel, ou afficher « Au nom de » et révéler l’expéditeur (votre fournisseur de services de courriel) en plus de l’adresse d’expéditeur. Pour configurer SPF et DKIM, vous devez créer des enregistrements TXT pour votre domaine. Les valeurs des enregistrements TXT et les autres détails du processus varient ; suivez donc les instructions de votre fournisseur de services de courriel pour cette configuration. En général, l’enregistrement TXT pour SPF doit avoir le nom d’hôte défini à @ ou laissé vide, et la valeur définie à v=spf1 include:<YOUR_PROVIDER_SPF_DOMAIN> -all. L’enregistrement TXT pour DKIM doit avoir le nom d’hôte défini sur le domaine que vous utilisez pour envoyer des courriels, et la valeur définie à la signature DKIM que vous générez avec votre fournisseur.

Objet

Le champ Objet définit l’objet du courriel. S’il n’est pas défini, Auth0 renseigne automatiquement l’objet selon le type de courriel.

Message

Le champ Message sert à définir le contenu HTML du corps du message. Chaque modèle comprend un corps de message par défaut, que vous pouvez modifier ou supprimer complètement pour rédiger le vôtre.

URL lifetime et Redirect To

Les modèles de courriel qui incluent un lien (Verification Email (Link), Change Password (Link) et Blocked Account Email) comportent deux champs supplémentaires pour gérer ces liens :

Le champ URL lifetime définit combien de temps un lien reste valide avant d’expirer. Par défaut, sa durée de validité est de 432 000 secondes (cinq jours).
Le champ Redirect To définit l’URL vers laquelle l’utilisateur est redirigé après avoir effectué l’action associée au lien inclus.

Les tenants créés à compter du 5 mai 2026 et ayant un abonnement non Enterprise ne peuvent pas personnaliser le champ Redirect To (resultUrl dans la Management API). Les tenants créés avant cette date sont exemptés, quel que soit le type d’abonnement. Cette restriction a été ajoutée pour atténuer un vecteur d’abus de redirection ouverte.Toute tentative de définir resultUrl sur un tenant concerné renvoie :

403 — Customizations for resultUrl are not allowed for non-enterprise tenants

Pour personnaliser le champ Redirect To sur un tenant non Enterprise créé à compter du 5 mai 2026, communiquez avec votre équipe de compte Auth0 afin de discuter d’une mise à niveau de votre abonnement.

Universal Login ignore actuellement la valeur du champ Redirect To dans le modèle Password Reset et redirige plutôt vers la route de connexion par défaut ou une page d’erreur.Pour personnaliser l’URL Redirect To de réinitialisation du mot de passe lorsque vous utilisez Universal Login, utilisez api.transaction.setResultURL() du déclencheur post-challenge d’Actions

Deux paramètres de requête sont ajoutés à l’URL Redirect To :

success défini à true ou false, pour indiquer si l’action a réussi
message défini comme description supplémentaire du résultat, par exemple « L’accès a expiré. » ou « Votre adresse e-mail a été vérifiée. Vous pouvez continuer à utiliser l’application. »

Si vous rencontrez des problèmes avec l’emplacement des paramètres de requête dans les URL Redirect To pour les applications monopage (SPA), la solution de contournement suivante pourrait vous aider.

Solution de contournement pour les paramètres de requête de l’URL Redirect To dans les SPA

RFC 3986 définit l’ordre attendu d’une URL comme scheme|authority|path|query|fragment. Toutefois, les frameworks SPA (comme Angular) s’attendent généralement à des URL au format scheme|authority|path|fragment|query, où la requête vient après le fragment.Cela peut poser un problème quant à l’emplacement des paramètres de requête dans les URL Redirect To. Si l’URL Redirect To de votre SPA est http://localhost:3000/#/register, l’utilisateur est redirigé vers http://localhost:3000/?exampleParameter=exampleValue#/register plutôt que vers http://localhost:3000/#/register?exampleParameter=exampleValue.Pour contourner cette limitation des frameworks SPA, vous pouvez :

Ajouter une URL côté serveur comme URL Redirect To, avec un paramètre route qui enregistre la route SPA à utiliser pour la redirection. Par exemple, http://localhost:3000/register?route=register.

Créer un contrôleur de route côté serveur qui lit route et les autres paramètres de l’URL, redirige vers la route SPA indiquée dans le paramètre route, puis ajoute les autres paramètres reçus d’Auth0. Par exemple :

var express = require('express');
var router = express.Router();
// Pour lire les paramètres de chaîne de requête et les convertir en chaîne :
var qs = require('qs');

router.get('/register', function(req, res, next) {
    // Récupérer le paramètre route qui contient la route
    // côté client de la SPA vers laquelle l’utilisateur doit être redirigé.
    var route = req.query.route;

    // Supprimer route des paramètres de requête.
    delete req.query.route;

    // Envoyer une redirection 302 vers la route attendue.
    res.redirect('http://localhost:3000/#/' + route + '?' +  qs.stringify(req.query));
});

module.exports = router;

Tester les modèles mis à jour

Pour tester, cliquez sur Try, saisissez une adresse courriel valide que vous pouvez consulter, puis choisissez le type de connexion approprié. Auth0 envoie le courriel pour une application par défaut qui porte le nom de votre tenant (et non le nom convivial de votre tenant). Pour tester les modèles pour différentes applications, créez un exemple d’utilisateur afin de parcourir les flux pertinents. Vous pouvez déclencher manuellement des courriels de vérification pour des applications et des utilisateurs précis à l’aide du point de terminaison Send an email address verification email de la Management API.

Exemples de cas d’utilisation de personnalisation

La personnalisation des modèles de courriel permet de répondre à de nombreux cas d’utilisation. Par exemple :

URL Redirect To dynamique

Vous pouvez configurer différentes URL Redirect To selon le nom de votre application. Par exemple :

{% if application.name == 'JWT.io' %}
    https://jwt.io
{% else %}
    https://auth0.com
{% endif %}

Comme le nom de l’application est encodé pour des raisons de sécurité, utilisez une valeur encodée (surtout si le nom de votre application contient un caractère qui change une fois encodé). Par exemple, utilisez My%20App au lieu de My App.

Objet et Message multilingues

À l’aide de Liquid, vous pouvez utiliser le paramètre request_language pour récupérer la langue à partir de la valeur de l’en-tête, ou utiliser par défaut la langue définie dans le navigateur de l’utilisateur.Par exemple :

{% 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 %}

Vous pouvez également utiliser la propriété user_metadata.lang pour adapter le contenu selon la langue préférée de l’utilisateur. Par exemple, vous pouvez utiliser une Action pour définir la propriété user_metadata.lang, puis lire le paramètre user_metadata.lang dans vos modèles de courriel afin d’envoyer des courriels dans la langue appropriée.

Pour un contrôle plus précis, vous pouvez envoyer des courriels en dehors de leurs flux de travail habituels et créer des tickets (des URL générées pour des actions de flux de courriel, comme les réinitialisations de mot de passe) à l’aide de la Management API. Les points de terminaison de courriel et de ticket de la Management API comprennent des paramètres supplémentaires qui vous permettent de personnaliser leur comportement. Pour en savoir plus, consultez Personnaliser la gestion des courriels et des tickets avec la Management API.

Quickstarts

Auth0 Overview

Configure Auth0

Applications

Personnaliser les modèles de courriel