Google Cloud - TECH PLAY - TECH PLAY

TECH PLAY

Google Cloud

イベント

マガジン

技術ブログ

G-gen の中川です。Google Workspace の移行期やシステム運用の現場で役立つ テストドメインエイリアス ( test-google-a.com )について、その仕組みと具体的な使用方法を解説します。 概要 テストドメインエイリアスとは 仕様 ユースケース1 : 段階的なシステム移行のための二重配信 ユースケース2 : 内部解決への対策 内部解決が発生する仕組み 内部解決を解消する方法 メール転送のための受信ゲートウェイ設定 概要 テストドメインエイリアスとは テストドメインエイリアス とは、Google Workspace のプライマリドメインを登録した際に、システムによって自動的に追加されるドメインエイリアスです。 通常、プライマリドメインが example.com である場合、 example.com.test-google-a.com という形式のドメインが自動生成されます。このテストドメインエイリアスは、Google Workspace を本番稼働させる前や、他社メールシステムからの段階的な移行期におけるメールのテストや転送に使用できます。 このドメイン宛てに送信されたメールは、通常のプライマリドメイン宛てと同様に、対象ユーザーの Google Workspace メールボックスに直接配送されます。また、既存の本番環境の MX レコード(DNS 設定)を変更しなくても Google Workspace 側の受信用アドレスとして機能します。 参考 : 二重配信を使用して複数の受信トレイにメールを配信する - テスト ドメイン エイリアスについて 仕様 テストドメインエイリアスは Google Workspace の基本機能として提供されているため、追加料金は発生せず無料で使用できます。また、グループメールアドレスでも使用できます。 Google Workspace のドメイン所有権確認が完了すると、自動的に有効化されます。 注意点として、テストドメインエイリアスはプライマリドメインのユーザーにのみ割り当てられます。後から追加したセカンダリドメインやユーザーエイリアスドメインのユーザーに対しては生成されません。 参考 : テスト用メールアドレス ユースケース1 : 段階的なシステム移行のための二重配信 他社のメールサーバー(オンプレミスの Exchange や他のホスティングサービス)から Google Workspace(Gmail)へ移行する際、使用される方法が 二重配信 です。 二重配信とは、既存のメールシステムに届いたメールのコピーを Google Workspace にも転送し、双方のメールボックスに同じメールを届ける手法を指します。これにより、ユーザーは既存システムを使い続けながら Google Workspace の操作感をテストできます。 二重配信を実現するアプローチには既存システム側で設定を行うサーバーベースの転送方法があります。当記事では、安全かつ手軽に検証環境を構築できる、テストドメインエイリアスを使用した方法を解説します。 本番環境の DNS の MX レコードが、現行の(Gmail に切り替える前の)メールサーバーを指している状態で、Google Workspace のユーザー( user@example.com )にメールを届けるためには、現行のメールシステムの転送設定でテストドメインエイリアス( user@example.com.test-google-a.com )を使用します。 具体的なメールの経路は以下のとおりです。 外部の送信者が user@example.com 宛てにメールを送信する DNS の MX レコードに基づき、現行のメールサーバーがメールを受信する 現行のメールサーバー側で、受信したメールのコピーを user@example.com.test-google-a.com 宛てに自動転送する Google 側で test-google-a.com 宛てのメールを受信し、Google Workspace の user@example.com のメールボックスへ配送する 二重配信 この方法を使用することで、本番環境の DNS レコード( example.com の MX レコード)を Google Workspace 側に切り替える前に、実際のメールフローを用いた本番さながらの受信テストができます。 参考 : 二重配信を使用して複数の受信トレイにメールを配信する - サーバーベースの転送(推奨) 参考 : 二重配信を使用して複数の受信トレイにメールを配信する - オプション 2: 既存のサーバーをプライマリ サーバーとして設定する ユースケース2 : 内部解決への対策 内部解決が発生する仕組み 本番の MX レコードを Google Workspace に向けて設定完了した後でも、自社 Web サイトのお問い合わせフォームからのメールだけが Google Workspace に届かないトラブルが発生することがあります。この現象は、Web サーバーでの 内部解決 が原因で発生します。 この現象は、一般的なレンタルサーバー(Web サーバー機能と SMTP サーバー機能が同居している環境)を使用しており、後からメール機能だけを Google Workspace に移行した場合などによく発生します。 例えば Web サーバー上にある WordPress のフォームから、自社の代表アドレス( info@example.com )宛てに通知を送るとします。この時、メールを送信する SMTP サーバー(Postfix など)は、「 example.com は自分が管理しているドメインだ」と設定されたままになっています。そのため、メールサーバーはわざわざインターネット上の外部 DNS に配送先(MX レコード)を問い合わせず、「自分宛てだから内部で処理しよう」と判断し、同じサーバー内の受信トレイに配送して処理を完了させてしまいます。 結果として、外部からのメールは正常に届くのに、自社の Web フォームからの通知だけが Google Workspace の info@example.com に届かないという現象が発生します。 内部解決の仕組み 内部解決を解消する方法 この内部解決問題を解消するために、テストドメインエイリアスを使用します。Web サーバーのローカル配信設定を変更できない、あるいは内部処理を維持する必要がある場合でも、テストドメインエイリアス宛ての転送設定を追加することで Google Workspace へメールを配送できます。 Web サーバー内のメール転送設定を使用して、 info@example.com 宛てのメールを info@example.com.test-google-a.com へ転送するように設定します。 test-google-a.com ドメイン宛てにメールが転送される際、インターネット上の外部 DNS を参照するため Google Workspace のメールサーバーへ配送されます。 テストドメインエイリアスを使用した場合 メール転送のための受信ゲートウェイ設定 「ユースケース」で紹介したようなテストドメインエイリアスを用いたメール転送の運用を開始するにあたり、Google Workspace 管理コンソール上で既存のメールサーバーを 受信ゲートウェイ に設定することで、大量メールをスムーズに受信でき、転送されたメールが「なりすまし(迷惑メール)」と誤判定されるのを防げます。 この設定は必須ではありませんが、推奨されます。 参考 : 受信メールのゲートウェイを設定する 中川 涼介 (記事一覧) クラウドソリューション部 クラウドサポート課 2024年11月、G-genに入社。Google Cloudを日々勉強中。 最近は怪談の動画にハマってます。
はじめに 株式会社AJA でバックエンドエンジニアをしている片山です。 AJA DSP では、Goo ...

動画

書籍