> ## 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 メールプロバイダーを設定](/ja/docs/customize/email/smtp-email-providers)する必要があります。Auth0 の組み込みメールプロバイダーを使用している場合は、メールテンプレートを利用できません。
</Warning>

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

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

1. [Dashboard > Branding > Email Templates](https://manage.auth0.com/#/templates) に移動します。

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

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

   **From address**、**Subject**、**Redirect To**、**Message** の各フィールドでは Liquid を使用できます。詳しくは、[サポートされている Liquid 構文](/ja/docs/customize/email/email-templates/supported-liquid-syntax) を参照してください。

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

<div id="from-address">
  ### 送信元アドレス
</div>

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

**送信元アドレス** フィールドを設定する場合、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>

**Message** フィールドでは、メッセージ本文の 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">
  Universal Login は現在、**Password Reset** テンプレートの **Redirect To** フィールドの値を無視し、代わりに [デフォルトのログインルート](/ja/docs/authenticate/login/auth0-universal-login/configure-default-login-routes) または [エラーページ](/ja/docs/authenticate/login/auth0-universal-login/error-pages) にリダイレクトします。

  Universal Login の使用時にパスワードリセットの **Redirect To** URL をカスタマイズするには、[`post-challenge` Actions トリガーの `api.transaction.setResultURL()`](/ja/docs/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="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 を使用](/ja/docs/customize/actions/actions-overview)して `user_metadata.lang` プロパティを設定し、その後メールテンプレートで `user_metadata.lang` パラメーターを読み取ることで、適切な言語でメールを送信できます。
  </Accordion>
</AccordionGroup>

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

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