所有するドメインに対して、MultiTEL がお客様のサービス向けに確認するホスト名と DNS 値を使い、ブランド付きポータビリティツールのドメインと認証済みメール送信を設定します。これらの設定は電話番号の移転とは別です。
この設定の目的
自社ブランド（ホワイトラベル）の番号ポータビリティツールを使うと、番号移転リクエストをお客様自身のブランドで提示でき、設定した場合はお客様自身のメールドメインの代理としてリクエストメールを送信できます。このガイドの DNS 変更は、そのブランド付きウェブサイトとメール識別情報に適用されます。これらは通常の電話番号移転の要件ではなく、電話番号の音声ルーティングも変更しません。
DNS を変更するドメインは、お客様が所有し管理していなければなりません。所有していない第三者のフリーメールドメイン上のアドレスに対して、これらのレコードを設定することはできません。
DNS を変更する前にブランド付きサービスを確認する
番号ポータビリティ を開いてください。そこのブランディング欄を使い、その画面のリクエストに使用するブランド名とロゴを設定してください。カスタムドメインの自社ブランド（ホワイトラベル）のサイトの場合は、DNS レコードを公開する前に、どのブランド設定が適用されるか、ホスト名、公開する DNS 値、送信者ドメイン、お客様のアカウントの HTTPS 証明書の設定を MultiTEL サポートに確認してください。
ポータビリティリクエストにブランドを付けるためだけに、既存の本番ウェブサイトをリダイレクトしたり、既存のメール配信を変更したりしないでください。必要に応じて復元できるよう、以前の DNS 値を記録してください。後の変更やロールバックをより速く伝播させる必要がある場合は、対象レコードの TTL をあらかじめ下げ、変更を行う前に以前の TTL が切れるまで待ってください。TTL を下げても、既存のキャッシュ済み応答はすぐには期限切れになりません。
ウェブサイトの CNAME
MultiTEL がお客様のサービスのカスタムホスト名と CNAME ターゲットを確認したあと、DNS プロバイダーで要求された CNAME を作成してください。DNS コンソールがゾーン名を自動的に付加するかどうかを確認し、ドメインを重複させずに、そのコンソールの指示に従ってホストラベルまたは完全名を入力してください。確認済みの CNAME ホスト名には、A、AAAA、MX、TXT レコードを同時に持たせてはなりません。そこに他のレコードがすでに存在する場合は、変更する前にどのサービスがそれらを使用しているかを確認してください。その名前がまだ別のサービスに使われている場合は、MultiTEL が承認した別のホスト名を使用してください。既存のレコードは、不要になったことを確認したあとでのみ削除してください。
以下は例にすぎません。これは、お客様が test123.com を所有しており、かつ MultiTEL がホスト名として porting.test123.com と、お客様のサービスの CNAME ターゲットとして porting.multitel.net の両方を確認した場合に適用されます。サポートがお客様のサービス向けにこのターゲットを確認しない限り、このターゲットを使用しないでください:
porting.test123.com. IN CNAME porting.multitel.net.お客様のサービス向けに確認された正確なターゲットを使用してください。CNAME だけではカスタムドメインは有効化されず、有効な HTTPS 証明書も保証されません。新しい URL を共有する前に、サイトの証明書とブランド付きリクエストフローを確認してください。
リクエストメールの SPF
MultiTEL がリクエストメールをお客様のドメインの代理として送信することを確認した場合は、SPF に使用する送信ドメインと DKIM に使用する署名ドメインをサポートに特定してもらってください。これらはブランド付きウェブサイトのホスト名である必要はありません。確認済みの SPF ドメインに SPF を公開し、DKIM 公開鍵は後述のセレクター固有の名前に公開してください。ウェブサイトの CNAME ホスト名にメール認証用の TXT レコードを追加しないでください。確認済みの送信サービスを、SPF ドメインのポリシーで許可してください。ここに示す MultiTEL の SPF include は include:_spf.multitel.net です。サポートが、お客様のアカウントの送信サービスにこれが適用されると確認したあとでのみ追加してください。
ドメインにすでに SPF TXT レコードがある場合は、許可された include をその既存のポリシーに統合してください。他の正当な送信者と意図した最終ポリシーは保持し、2つ目の SPF レコードは公開しないでください。入れ子の include と redirect を含め、ポリシー全体を SPF の DNS ルックアップ上限 に照らして確認してください。SPF の評価では、DNS ルックアップを発生させる項は最大 10 個まで許可されます。例として include、a、mx、ptr、exists および redirect があります。この上限を超えると permerror になります。壊れた SPF ポリシーがあると、正当なメールが SPF 認証を通過できなくなることがあります。既存のポリシーがなく、MultiTEL がこれが唯一の許可された送信者であると確認した場合の例は次のとおりです:
@ IN TXT "v=spf1 include:_spf.multitel.net ~all"リクエストメールの DKIM
お客様の署名ドメインについて確認された、正確な DKIM セレクター、DNS レコード名、公開鍵 TXT 値を公開してください。DKIM の DNS 名 は、セレクター、_domainkey、署名ドメインを組み合わせたものです。たとえば、example.com のセレクター mail は、完全なレコード名 mail._domainkey.example.com になります。mail._domainkey は相対レコード名であり、セレクターではありません。現行の値は MultiTEL サポートから入手してください。古い記事、別のアカウント、または MultiTEL 自身の DNS からコピーしたセレクターや公開鍵を、お客様のアカウントで使用される値だと想定しないでください。DKIM 公開鍵は DNS に公開します。秘密の署名鍵を決して要求したり公開したりしてはなりません。
DNS コンソールがゾーン名を自動的に付加するかどうかを確認し、レコード名でドメインや _domainkey を重複させないようにしてください。DNS コンソールが長い TXT レコードを引用符付きのチャンクに分割する場合は、公開鍵の値を完全に保持してください。
結果全体を検証する
変更した各レコードについて、権威ネームサーバーと外部リゾルバーに照会してください。設定された TTL と DNS キャッシュの有効期限が切れるまで待ってください。キャッシュされた 1 つのローカルリゾルバーからの結果では不十分です。完全修飾レコード名、種類、正確なターゲットまたは値、引用符、末尾のドットを、確認済みの指示と DNS プロバイダーの入力形式と照合してください。URL を共有したりブランド付きメールに依存したりする前に、競合するレコード、誤った名前、欠落した値、無効な証明書を解消してください。
確認済みのブランド付きリクエスト URL を開き、ページが有効な証明書と想定どおりのブランドで読み込まれることを確認してください。テストを送信する前に、どのテストフローが利用可能か、送信すると実際の番号移転が開始されるかどうかを MultiTEL サポートに確認してください。サポートがお客様のアカウントでブランド付きメールが有効になっていることを確認したあと、確認済みのテストフローでのみ、かつサポートが提供するサンプルデータまたはテスト手順を使ってテストし、実際の番号移転を開始しないようにしてください。受信したメッセージの SPF と DKIM の認証結果を確認してください。返信とリクエストリンクが意図した宛先に届くことを確認してください。置き換えが検証されるまで以前のサービスとレコードを利用可能な状態に保ち、MultiTEL が置き換え済みと確認したレコードのみを削除してください。