> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<Warning>
  メールテンプレートをカスタマイズするには、[外部 SMTP メールプロバイダーを設定](/docs/ja-jp/customize/email/smtp-email-providers)する必要があります。Auth0 の組み込みメールプロバイダーを使用している場合、メールテンプレートは利用できません。
</Warning>

<div id="customize-email-templates">
  ## メールテンプレートをカスタマイズする
</div>

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

1. [Auth0 Dashboard > Branding > メールテンプレート](https://manage.auth0.com/#/templates) に移動します。

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

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

   **From Address**、**件名**、**Redirect To**、**メッセージ** フィールドでは Liquid を使用できます。詳しくは、[Supported Liquid Syntax](/docs/ja-jp/customize/email/email-templates/supported-liquid-syntax) を参照してください。

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

<div id="from-address">
  ### From Address
</div>

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

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

* [Sender Policy Framework (SPF)](https://en.wikipedia.org/wiki/Sender_Policy_Framework)：特定の IP アドレスに、ドメインからのメール送信を許可します

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

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

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

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

<div id="subject">
  ### 件名
</div>

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

<div id="message">
  ### メッセージ
</div>

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

<div id="url-lifetime-and-redirect-to">
  ### URL の有効期間と Redirect To
</div>

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

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

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

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

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

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

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Universal Login では現在、**Password Reset** テンプレートの **Redirect To** フィールドの値は無視され、代わりに[デフォルトのログインルート](/docs/ja-jp/authenticate/login/auth0-universal-login/configure-default-login-routes)または[エラーページ](/docs/ja-jp/authenticate/login/auth0-universal-login/error-pages)にリダイレクトされます。

  Universal Login 使用時にパスワードリセットの **Redirect To** URL をカスタマイズするには、[`post-challenge` Actions トリガーの `api.transaction.setResultURL()`](/docs/ja-jp/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-api-object#api-transaction-setresulturl-url,-options) を使用してください
</Callout>

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

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

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

<Accordion title="SPA における Redirect To URL クエリパラメータの回避策">
  [RFC 3986](https://tools.ietf.org/html/rfc3986#section-3) では、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 から受け取った他のパラメータを追加するサーバーサイドのルートコントローラーを作成します。

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

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

<div id="test-updated-templates">
  ## 更新したテンプレートをテストする
</div>

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

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

特定のアプリケーションやユーザーに対しては、Management API の [Send an email address verification email](https://auth0.com/docs/api/management/v2#!/Jobs/post_verification_email) エンドポイントを使用して、確認メールを手動で送信できます。

<div id="example-customization-use-cases">
  ## カスタマイズのユースケース例
</div>

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

<AccordionGroup>
  <Accordion title="動的な Redirect To URL">
    アプリケーション名に応じて、異なる **Redirect To** URL を設定できます。たとえば、次のようになります。

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

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

  <Accordion title="多言語の件名とメッセージ">
    Liquid を使用すると、`request_language` パラメーターを使ってヘッダーの値から言語設定を取得したり、ユーザーのブラウザーの言語設定を既定値として使用したりできます。

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

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

    また、`user_metadata.lang` プロパティを使用して、ユーザーの優先言語に応じてコンテンツを変更することもできます。たとえば、[Action を使用](/docs/ja-jp/customize/actions/actions-overview)して `user_metadata.lang` プロパティを設定し、その後、メールテンプレート内で `user_metadata.lang` パラメーターを読み取ることで、適切な言語のメールを送信できます。
  </Accordion>
</AccordionGroup>

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

詳しくは、[Management API を使用したメールとチケット処理のカスタマイズ](/docs/ja-jp/customize/email/manage-email-flow)を参照してください。