Skip to main content
To customize email templates, you must configure an external SMTP email provider. Email templates are not available when using Auth0’s built-in email provider.

​
Customize email templates

To customize an email template:
  1. Go to Dashboard > Branding > Email Templates.
  2. From the Template dropdown, select the email template you want to update.
  3. On the email template page, update the fields you want to customize. The From address, Subject, Redirect To, and Message fields support Liquid. To learn more, read Supported Liquid Syntax.
  4. Click Save to save your changes, Try to test your changes, or Reset to revert your changes.

​
From Address

The From Address field sets the email address users see as the sender when receiving an email from Auth0. If unset, emails use the email address in the From field configured for your email provider. When setting the From Address field, to allow Auth0 to send digitally-signed emails on your behalf, you must configure two forms of email authentication: Without SPF and DKIM configured, the emails may not be delivered, may be caught by spam filters, or may display “On Behalf Of” and expose the sender (your email provider) in addition to the from address. To configure SPF and DKIM, you need to create TXT records for your domain. The values for the TXT records and other process details vary, so follow your email provider’s instructions for this configuration. In general, the TXT record for SPF should have the host name set to @ or empty, and the value to v=spf1 include:<YOUR_PROVIDER_SPF_DOMAIN> -all. The TXT record for DKIM should have the host name set to the domain you use to send emails and the value set to the DKIM signature you generate with your provider.

​
Subject

The Subject field sets the subject line of the email. If unset, Auth0 automatically populates the subject depending on the type of email.

​
Message

The Message field sets the HTML content of the message body. Each template comes with a default message body which you can modify or discard entirely to write your own.

​
URL Lifetime and Redirect to

Email templates that include a link (Verification Email (Link), Change Password (Link), and Blocked Account Email) have two additional fields to manage these links:
  • The URL lifetime field sets how long a link remains valid before it expires. By default, the lifetime is 432,000 seconds (five days).
  • The Redirect To field sets a URL where a user is redirected after completing the action at an included link.
Universal Login currently ignores the value of the Redirect To field in the Password Reset template and instead redirects to the default login route or an error page.To customize the password reset Redirect To URL when using Universal Login, use api.transaction.setResultURL() from the post-challenge Actions trigger
Two query parameters are appended to the Redirect To URL:
  • success set to true or false indicating whether the action was successful
  • message set to an additional description of the outcome, like “Access expired.” or “Your email was verified. You can continue using the application.”
If you have issues with the placement of query parameters in Redirect To URLs for single-page applications (SPAs), the following workaround may help.
RFC 3986 defines the expected order of a URL as scheme|authority|path|query|fragment. However, SPA frameworks (like Angular) typically expect URLs in the scheme|authority|path|fragment|query format, which has the query after the fragment.This can cause an issue with the placement of query parameters in Redirect To URLs. If your SPA’s Redirect To URL is http://localhost:3000/#/register, the user is redirected to http://localhost:3000/?exampleParameter=exampleValue#/register instead of to http://localhost:3000/#/register?exampleParameter=exampleValue.To work around this limitation of SPA frameworks, you can:
  1. Add a server-side URL as the Redirect To URL with a route parameter that records the SPA route for the redirect. For example, http://localhost:3000/register?route=register.
  2. Create a server-side route controller that reads the route and other parameters from the URL, redirects to the SPA route specified in route parameter, and appends the other parameters received from Auth0. For example: 
    var express = require('express');
var router = express.Router();
// To read query strings params and stringify them:
var qs = require('qs');

router.get('/register', function(req, res, next) {
    // Retrieve the route param that contains the SPA client side
    // route that the user needs to be redirected to.
    var route = req.query.route;

    // Remove route from the query parameters.
    delete req.query.route;

    // Send a 302 redirect for the expected route.
    res.redirect('http://localhost:3000/#/' + route + '?' +  qs.stringify(req.query));
});

module.exports = router;

​
Test updated templates

To test, click Try, enter a valid email address that you have access to view, and choose the correct connection type. Auth0 sends the email for a default app that shares your tenant name (not your tenant’s friendly name). To test templates for different applications, create a sample user to go through the relevant flows. You can trigger verification emails manually for specific applications and users using the Management API Send an email address verification email endpoint.

​
Example customization use cases

Customizing email templates enables many use cases. For example:
You can set up different Redirect To URLs based on your application name. For example:
{% if application.name == 'JWT.io' %}
    https://jwt.io
{% else %}
    https://auth0.com
{% endif %}
Because the application name is encoded for security, use an encoded value (especially if your application name contains a character that changes once encoded). For example, use My%20App instead of My App.
Using Liquid, you can use the request_language parameter to pull the language setting from the header value or default to the user’s browser language setting.For example:
{% 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 %}
You can also use the user_metadata.lang property to alter the content based on the user’s preferred language. For example, you can use an Action to set the user_metadata.lang property, then read the user_metadata.lang parameter in your email templates to send emails in the appropriate language.
For more granular control, you can send emails outside of their standard workflows and create tickets (generated URLs for email workflow actions, like password resets) using the Management API. The Management API’s email and ticket endpoints have additional parameters that let you customize their behavior. To learn more, read Customize Email and Ticket Handling with the Management API.