メールテンプレートをカスタマイズ

メールテンプレートを使用して、Auth0 のメールベースのワークフローで送信されるメールの見た目や内容をカスタマイズする方法を説明します。

メールテンプレートをカスタマイズするには、外部 SMTP メールプロバイダーを設定する必要があります。Auth0 の組み込みメールプロバイダーを使用している場合、メールテンプレートは利用できません。

​

メールテンプレートをカスタマイズする

メールテンプレートをカスタマイズするには、次の手順に従います。

1. Auth0 Dashboard > Branding > メールテンプレート に移動します。

2. Template ドロップダウンで、更新するメールテンプレートを選択します。

3. メールテンプレートのページで、カスタマイズするフィールドを更新します。

   From Address、件名、Redirect To、メッセージ フィールドでは Liquid を使用できます。詳しくは、Supported Liquid Syntax を参照してください。

4. 変更を保存するには Save、変更をテストするには Try、変更を元に戻すには Reset をクリックします。

​

From Address

From Address フィールドでは、Auth0 からのメールを受信した際に、送信者としてユーザーに表示されるメールアドレスを設定します。未設定の場合、メールにはメールプロバイダーで設定した From フィールドのメールアドレスが使用されます。

From Address フィールドを設定する際に、Auth0 が代理で電子署名付きメールを送信できるようにするには、2 種類のメール認証を設定する必要があります。

• Sender Policy Framework (SPF)：特定の IP アドレスに、ドメインからのメール送信を許可します

• DomainKeys Identified Mail (DKIM)：メールに暗号学的署名を付与し、メールサーバーがそのメールが示されたドメインから送信されたものであることを検証できるようにします

SPF と DKIM が設定されていない場合、メールが配信されなかったり、迷惑メールフィルターに振り分けられたり、“On Behalf Of” と表示されて、from アドレスに加えて送信者 (メールプロバイダー) が表示されたりすることがあります。

SPF と DKIM を設定するには、ドメイン用の TXT レコードを作成する必要があります。TXT レコードの値やそのほかの手順の詳細は環境によって異なるため、この設定についてはメールプロバイダーの案内に従ってください。

一般的に、SPF の TXT レコードでは、ホスト名を @ または空欄に設定し、値を v=spf1 include:<YOUR_PROVIDER_SPF_DOMAIN> -all にします。DKIM の TXT レコードでは、ホスト名をメール送信に使用するドメインに設定し、値をプロバイダーで生成した DKIM 署名に設定します。

​

件名

件名フィールドでは、メールの件名を設定します。未設定の場合、Auth0 がメールの種類に応じて件名を自動的に設定します。

​

メッセージ

メッセージフィールドでは、メッセージ本文のHTMLコンテンツを設定します。各テンプレートには既定のメッセージ本文が用意されており、これを編集したり、完全に削除して独自の内容を作成したりできます。

​

URL の有効期間と Redirect To

リンクを含むメールテンプレート (Verification Email (Link)、Change Password (Link)、Blocked Account Email) には、これらのリンクを管理するための追加フィールドが 2 つあります。

• URL lifetime フィールドでは、リンクが失効するまでの有効期間を設定します。デフォルトの有効期間は 432,000 秒 (5 日間) です。

• Redirect To フィールドでは、リンク先のアクション完了後にユーザーをリダイレクトする URL を設定します。

2026 年 5 月 5 日以降に作成され、エンタープライズ以外のサブスクリプションを使用するテナントでは、Redirect To フィールド (Management API の resultUrl) をカスタマイズできません。この日より前に作成されたテナントは、サブスクリプションの種類にかかわらず対象外です。この制限は、オープンリダイレクトの悪用経路を軽減するために追加されました。

影響を受けるテナントで resultUrl を設定しようとすると、次の応答が返されます。

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

2026 年 5 月 5 日以降に作成されたエンタープライズ以外のテナントで Redirect To フィールドをカスタマイズするには、サブスクリプションのアップグレードについて Auth0 のアカウントチームにお問い合わせください。

Universal Login では現在、Password Reset テンプレートの Redirect To フィールドの値は無視され、代わりにデフォルトのログインルートまたはエラーページにリダイレクトされます。

Universal Login 使用時にパスワードリセットの Redirect To URL をカスタマイズするには、post-challenge Actions トリガーの api.transaction.setResultURL() を使用してください

Redirect To URL には、次の 2 つのクエリパラメータが追加されます。

• success には、アクションが成功したかどうかを示す true または false が設定されます
• message には、“Access expired.” や “Your email was verified. You can continue using the application.” のような、結果に関する追加の説明が設定されます

シングルページアプリケーション (SPA) の Redirect To URL におけるクエリパラメータの位置に問題がある場合は、次の回避策が役立つことがあります。

SPA における Redirect To URL クエリパラメータの回避策

RFC 3986 では、URL の想定される順序を scheme|authority|path|query|fragment と定義しています。一方、SPA フレームワーク (Angular など) では通常、クエリがフラグメントの後に来る scheme|authority|path|fragment|query 形式の URL が想定されています。

このため、Redirect To URL ではクエリパラメータの位置が問題になることがあります。SPA の Redirect To URL が http://localhost:3000/#/register の場合、ユーザーは http://localhost:3000/#/register?exampleParameter=exampleValue ではなく、http://localhost:3000/?exampleParameter=exampleValue#/register にリダイレクトされます。

SPA フレームワークのこの制限を回避するには、次の方法があります。

1. リダイレクト先の SPA ルートを記録する route パラメータを含むサーバーサイド URL を、Redirect To URL として追加します。

   たとえば、http://localhost:3000/register?route=register です。

2. URL から route とその他のパラメータを読み取り、route パラメータで指定された SPA ルートにリダイレクトしたうえで、Auth0 から受け取った他のパラメータを追加するサーバーサイドのルートコントローラーを作成します。

   たとえば、次のようになります。

   var express = require('express');
   var router = express.Router();
   // クエリ文字列のパラメータを読み取り、文字列化するには:
   var qs = require('qs');
   
   router.get('/register', function(req, res, next) {
       // ユーザーのリダイレクト先となる SPA クライアント側の
       // ルートを含む route パラメータを取得します。
       var route = req.query.route;
   
       // クエリパラメータから route を削除します。
       delete req.query.route;
   
       // 想定されるルートに対して 302 リダイレクトを送信します。
       res.redirect('http://localhost:3000/#/' + route + '?' +  qs.stringify(req.query));
   });
   
   module.exports = router;
   

​

更新したテンプレートをテストする

テストするには、Try をクリックし、確認可能な有効なメールアドレスを入力して、正しい接続タイプを選択します。Auth0 は、テナント名 (テナントのフレンドリー名ではありません) と同じ名前のデフォルトのアプリケーションに対してメールを送信します。

別のアプリケーション用のテンプレートをテストするには、該当するフローを試せるサンプルユーザーを作成します。

特定のアプリケーションやユーザーに対しては、Management API の Send an email address verification email エンドポイントを使用して、確認メールを手動で送信できます。

​

カスタマイズのユースケース例

メールテンプレートをカスタマイズすると、さまざまなユースケースに対応できます。たとえば、次のようなものがあります。

動的な Redirect To URL

アプリケーション名に応じて、異なる Redirect To URL を設定できます。たとえば、次のようになります。

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

アプリケーション名はセキュリティ上の理由でエンコードされるため、エンコード後の値を使用してください (特に、エンコードされると変化する文字がアプリケーション名に含まれている場合) 。たとえば、My App ではなく My%20App を使用します。

多言語の件名とメッセージ

Liquid を使用すると、request_language パラメーターを使ってヘッダーの値から言語設定を取得したり、ユーザーのブラウザーの言語設定を既定値として使用したりできます。

たとえば、次のようになります。

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

また、user_metadata.lang プロパティを使用して、ユーザーの優先言語に応じてコンテンツを変更することもできます。たとえば、Action を使用して user_metadata.lang プロパティを設定し、その後、メールテンプレート内で user_metadata.lang パラメーターを読み取ることで、適切な言語のメールを送信できます。

さらに細かく制御したい場合は、標準のワークフローとは別にメールを送信したり、Management API を使用してチケット (パスワードリセットなど、メールワークフローのアクション用に生成される URL) を作成したりできます。Management API のメールおよびチケットのエンドポイントには、その動作をカスタマイズするための追加パラメーターが用意されています。

詳しくは、Management API を使用したメールとチケット処理のカスタマイズを参照してください。