> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Customize Email Templates

> Instructions on how to use email templates to customize the appearance and content of emails sent by Auth0's email-based workflows.

<Warning>
  To customize email templates, you must [configure an external SMTP email provider](/docs/customize/email/smtp-email-providers). Email templates are not available when using Auth0's built-in email provider.
</Warning>

## Customize email templates

To customize an email template:

1. Go to [Dashboard > Branding > Email Templates](https://manage.auth0.com/#/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](/docs/customize/email/email-templates/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:

* [Sender Policy Framework (SPF)](https://en.wikipedia.org/wiki/Sender_Policy_Framework), which authorizes specific IP addresses to send email from a domain

* [DomainKeys Identified Mail (DKIM)](https://en.wikipedia.org/wiki/DKIM), which cryptographically signs emails so mail servers can verify that it was sent from the reported domain

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Tenants created on or after **May 5, 2026** with a non-enterprise subscription cannot customize the **Redirect To** field (`resultUrl` in the Management API). Tenants created before this date are exempt regardless of subscription type. This restriction was added to mitigate an open-redirect abuse vector.

  Attempting to set `resultUrl` on an affected tenant returns:

  ```text theme={null}
  403 — Customizations for resultUrl are not allowed for non-enterprise tenants
  ```

  To customize the **Redirect To** field on a non-enterprise tenant created on or after May 5, 2026, contact your Auth0 account team about upgrading your subscription.
</Callout>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Universal Login currently ignores the value of the **Redirect To** field in the **Password Reset** template and instead redirects to the [default login route](/docs/authenticate/login/auth0-universal-login/configure-default-login-routes) or an [error page](/docs/authenticate/login/auth0-universal-login/error-pages).

  To customize the password reset **Redirect To** URL when using Universal Login, use [`api.transaction.setResultURL()` from the `post-challenge` Actions trigger](/docs/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-api-object#api-transaction-setresulturl-url,-options)
</Callout>

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.

<Accordion title="Workaround for Redirect To URL query parameters in SPFs">
  [RFC 3986](https://tools.ietf.org/html/rfc3986#section-3) 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:

     ```javascript lines wrap theme={null}
     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;
     ```
</Accordion>

## 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](https://auth0.com/docs/api/management/v2#!/Jobs/post_verification_email) endpoint.

## Example customization use cases

Customizing email templates enables many use cases. For example:

<AccordionGroup>
  <Accordion title="Dynamic Redirect To URL">
    You can set up different **Redirect To** URLs based on your application name. For example:

    ```liquid theme={null}
    {% 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`.
  </Accordion>

  <Accordion title="Multilingual Subject and Message">
    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:

    ```liquid lines theme={null}
    {% 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](/docs/customize/actions/actions-overview) 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.
  </Accordion>
</AccordionGroup>

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](/docs/customize/email/manage-email-flow).