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

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

メールテンプレートをカスタマイズするには、次の手順に従います。
  1. Dashboard > Branding > Email Templates に移動します。
  2. Template ドロップダウンから、更新するメールテンプレートを選択します。
  3. メールテンプレートのページで、カスタマイズするフィールドを更新します。 From address、Subject、Redirect To、Message の各フィールドでは Liquid を使用できます。詳しくは、サポートされている Liquid 構文 を参照してください。
  4. 変更を保存するには Save、変更をテストするには Try、変更を元に戻すには Reset をクリックします。

​
送信元アドレス

送信元アドレス フィールドでは、Auth0 からメールを受信したときに、送信者としてユーザーに表示されるメールアドレスを設定します。設定しない場合、メールプロバイダーで設定した From フィールドのメールアドレスが使用されます。 送信元アドレス フィールドを設定する場合、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 がメールの種類に応じて件名を自動的に設定します。

​
メッセージ

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

​
URL の有効期間と Redirect To

リンクを含むメールテンプレート (Verification Email (Link)、Change Password (Link)、Blocked Account Email) には、これらのリンクを管理するための追加フィールドが 2 つあります。
  • URL lifetime フィールドでは、リンクの有効期限が切れるまでの期間を設定します。デフォルトの有効期間は 432,000 秒 (5 日間) です。
  • Redirect To フィールドでは、リンク先のアクション完了後にユーザーをリダイレクトする URL を設定します。
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 でクエリパラメーターの配置に問題がある場合は、次の回避策が役立つことがあります。
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 を切り替えることができます。たとえば、次のようになります。
{% 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 を使用したメールおよびチケット処理のカスタマイズを参照してください。