Google Workspaceのグループメールの基礎。グループのメールアドレスは「個人メール」と同じではありません
はじめに
Google Workspaceを導入するときに、意外と混乱しやすいのが「グループメール」の考え方です。
たとえば、
info@example.com
contact@example.com
sales@example.com
のようなメールアドレスを見ると、多くの方は「普通のメールアドレス」と同じように考えます。
しかし、Google Workspaceのグループメールは、個人ユーザーのメールアドレスとは仕組みが違います。
この違いを理解していないと、
・info@ はユーザーとして作るべきなのか
・グループとして作るべきなのか
・エイリアスでよいのか
・レンタルサーバー側に一部メールを残せるのか
・Google Workspaceと既存メールサーバーを併用できるのか
といった部分で混乱しやすくなります。
この記事では、Google Workspaceのグループメールの基礎と、レンタルサーバーのメールを併用したい場合の注意点、さらにテストドメインの考え方について整理します。
グループメールは「メールボックス」ではなく「配信先のまとまり」
Google Workspaceのグループメールは、基本的には複数のメンバーにメールを配信するための仕組みです。
たとえば、
というグループを作り、そこに、
tanaka@example.com
suzuki@example.com
sato@example.com
をメンバーとして登録すると、info@example.com 宛のメールを複数人で受け取ることができます。
つまり、グループのメールアドレスは、個人のGmailアカウントそのものではありません。
Googleの公式ヘルプでも、Googleグループは1つのアドレスで複数の人にメールを送ったり、共同作業や予定調整などに使うものとして説明されています。
Google Workspaceのユーザーとは何か
Google WorkspaceでGmail、Google Drive、Googleカレンダーなどを利用する人には、基本的にユーザーアカウントとライセンスが必要です。
Googleの公式ヘルプでも、組織内の人がGoogle Workspaceサービスを使うには、各ユーザーにアカウントとGoogle Workspaceライセンスを付与する必要があると説明されています。また、複数のユーザーで1つのGoogle Workspaceライセンスを共有することはできません。
そのため、Google Workspaceを導入するときは、
・誰がGoogle Workspaceを使うのか
・どのメールアドレスでログインするのか
・どのメールアドレスを個人用にするのか
・どのメールアドレスを代表メールにするのか
・代表メールはグループ、エイリアス、メール委任のどれで運用するのか
を先に整理する必要があります。
グループメールとユーザーアカウントの違い
分かりやすく言うと、次のようになります。
ユーザーアカウントは、ログインして使う人のためのアカウントです。
例：
tanaka@example.com
suzuki@example.com
このようなメールアドレスは、本人がGoogle Workspaceにログインし、GmailやGoogle Driveなどを使うためのものです。
一方で、グループメールは、複数人に配信するための宛先です。
例：
info@example.com
support@example.com
sales@example.com
このようなアドレスは、問い合わせ窓口や部署宛のメールを複数人で受け取るために使われることが多いです。
ただし、グループメールは「そのアドレス専用のGmail受信箱にログインする」という考え方とは異なります。
この違いを理解しておかないと、
「info@example.com でログインしたい」
「info@example.com の受信箱を直接見たい」
「でもライセンスは増やしたくない」
という相談になり、設定方法の整理が難しくなります。
代表メールの作り方は1つではない
Google Workspaceで代表メールを作る方法は、主に次のように分かれます。
1. グループメール
info@example.com 宛のメールを複数人に配信したい場合に使います。
新着メールを各担当者が気づきやすい形で受け取りたい場合に向いています。
2. エイリアス
1人のユーザーが、別名のメールアドレスも使いたい場合に使います。
たとえば、
というユーザーに、
をエイリアスとして追加すると、info@example.com 宛のメールもtanaka@example.comで受け取ることができます。
ただし、基本的には1人の別名として使う考え方です。
3. メール委任
1つのGoogle Workspaceユーザーのメールボックスを、他のユーザーが代わりに確認・送信する方法です。
たとえば、
をユーザーとして作成し、そのGmailを複数人に委任する形です。
メール履歴を1つのメールボックスにまとめたい場合には便利ですが、委任元のメールボックスを見に行く運用になるため、新着通知に気づきやすいかどうかは別途考える必要があります。
レンタルサーバーに一部メールを残したい場合の注意点
Google Workspace導入時に、よくある相談が、
「一部のメールアドレスだけGoogle Workspaceに移行し、残りはレンタルサーバーに残したい」
というものです。
たとえば、
tanaka@example.com はGoogle Workspace
suzuki@example.com はGoogle Workspace
info@example.com はレンタルサーバー
old@example.com はレンタルサーバー
のような構成です。
Google Workspaceには、2つのメールシステムにメールを配送する「分割配信」という考え方があります。
ただし、Google公式ヘルプの分割配信では、ドメインのMXレコードはGoogleを向いており、受信メールはいったんGmail側で処理され、その後、条件に応じてGoogle以外のメールサーバーへ転送される前提で説明されています。また、ユーザーはGmail側またはGoogle以外のメールシステム側のどちらかに存在し、両方には存在しない前提も示されています。
ここが重要です。
日本のレンタルサーバーでは、同じサーバー内のメール配送が独自に処理されることがあります。
そのため、Google Workspace側で分割配信を設定すれば必ず思い通りに動く、とは限りません。
特に、Webサイト、問い合わせフォーム、レンタルサーバーのメール機能、DNS、MXレコード、SPFなどが絡むと、メールの流れが複雑になります。
MXレコードを切り替える意味
Google WorkspaceでGmailを使う場合、ドメインのMXレコードをGoogle側に向ける必要があります。
Google公式ヘルプでは、メール送信者側は宛先ドメインのMXレコードを見て配送先を判断し、Google WorkspaceでGmailを使うには、ドメインのMXレコードをGoogleのメールサーバーに向ける必要があると説明されています。
つまり、Google Workspaceでメールを受け取る設定は、単に管理画面でユーザーを作るだけでは完了しません。
DNS側で、
「このドメイン宛のメールはGoogleに届ける」
という設定が必要になります。
そのため、同じドメイン内で、
一部はGoogle Workspace
一部はレンタルサーバー
という構成にする場合は、単純なメールアドレス追加だけでなく、メール配送全体の設計が必要になります。
基本は、利用しているメールアドレスをGoogle Workspace側へ整理して移行する方が安全
実務上は、会社で使っている主要なメールアドレスを、できるだけGoogle Workspace側へ整理して移行する方が分かりやすいです。
たとえば、
個人メールはユーザー
代表メールはグループ
1人の別名はエイリアス
1つの受信箱を複数人で管理する場合はメール委任
のように整理します。
もちろん、すべてのケースで完全移行が必須というわけではありません。
ただし、
・レンタルサーバー側に古いメールアドレスが残る
・一部の人だけGoogle Workspaceを使う
・一部の人はOutlookで従来メールを使う
・代表メールだけレンタルサーバーに残る
・問い合わせフォームの送信元が古い設定のまま残る
という状態が続くと、後からトラブルが起きたときに原因を特定しにくくなります。
そのため、Google Workspaceへ移行する場合は、最初にメールアドレス一覧を作り、
・現在使っているメールアドレス
・今後も使うメールアドレス
・廃止してよいメールアドレス
・ユーザーとして作るメールアドレス
・グループとして作るメールアドレス
・エイリアスにするメールアドレス
・既存メールの移行が必要なメールアドレス
を整理することが大切です。
テストドメインとは何か
ここで注意したいのが、「テストドメイン」という言葉です。
Google Workspaceの導入を検討するときに、
「まずテスト用のドメインで試したい」
「本番ドメインを触らずにGoogle Workspaceをテストしたい」
という考えが出ることがあります。
ただし、Google Workspaceの通常の申し込みでは、仮の名前ではなく、組織の実際のドメインで申し込むことが推奨されています。
Google公式ヘルプでは、数人のユーザーでGoogleサービスをテストするだけの場合でも、組織の実際のドメインを使って申し込むよう案内されています。また、そのドメインで既存のメールやWebサイトを使っている場合でも、既存のメールフローやWebサイトに影響なくGoogleサービスをテストできると説明されています。
つまり、通常のGoogle Workspace導入では、
「まったく別の仮ドメインで試す」
というより、
「実際に使うドメインをGoogle Workspaceに登録し、既存メールをすぐには切り替えずに、設定や動作を確認する」
という考え方が基本になります。
ドメインを登録しても、すぐにメールがGoogleへ切り替わるとは限らない
Google Workspaceでは、ドメインを登録しただけで、すぐにすべてのメールがGoogleに届くわけではありません。
Google Workspaceでドメインを使うには、まずそのドメインの所有権を確認する必要があります。
Google公式ヘルプでは、第三者が勝手に自社ドメインでGoogle Workspaceを使えないようにするため、DNS設定などでドメイン所有権を確認すると説明されています。また、ドメイン所有権の確認自体は、メールやWebサイトには影響しないと説明されています。
その後、Gmailで受信するにはMXレコードをGoogle側へ切り替える必要があります。
つまり、
ドメイン所有権の確認
Gmailの有効化
MXレコードの切り替え
は、それぞれ意味が違います。
この違いを理解しておくと、
「Google Workspaceにドメインを登録したら、すぐ既存メールが止まるのではないか」
という不安を減らせます。
Google Workspace for Educationの「テスト用ドメイン」
なお、Google Workspace for Educationには、公式ヘルプ上で「テスト用ドメイン」を作成する説明があります。
これは、既存のGoogle Workspace for Educationアカウントとは別のドメインで新機能を試したい場合に使うものです。
この場合、既存のGoogle Workspace for Educationのプライマリドメインのサブドメインを使い、Google側の承認チームがテスト用ドメインとして識別できるように、
gworkspacetest.domain.com
という形式にする必要があると説明されています。
たとえば、既存のGoogle Workspace for Educationのドメインが、
bestschool.com
であれば、
gworkspacetest.bestschool.com
のような形式です。
この点からも分かるように、Google Workspaceにおけるテストドメインは、自由に作った無関係なドメインを恒久運用するというより、実際の組織ドメインや既存のGoogle Workspace環境を前提に、検証用として使うものと理解した方が安全です。
テストドメインは本番運用の代替ではない
テストドメインやテスト用サブドメインは、Google Workspaceの設定確認には役立ちます。
たとえば、
・Google Workspaceにドメインを登録できるか
・ドメイン所有権の確認ができるか
・ユーザーを作成できるか
・グループメールを作成できるか
・Gmailの送受信を確認できるか
・SPF、DKIM、DMARCなどのメール認証を確認できるか
といった検証に使えます。
ただし、テストドメインは本番運用の代替ではありません。
本番ドメインでは、すでに次のようなものが関係していることがあります。
・既存のメールアドレス
・レンタルサーバー側のメール機能
・ホームページ
・問い合わせフォーム
・外部サービスに登録しているメールアドレス
・社員や担当者のメールソフト設定
・過去メールの移行
・SPF、DKIM、DMARCなどの認証設定
そのため、テストドメインで送受信に成功しても、本番ドメインの移行計画が不要になるわけではありません。
最終的には、
・本番ドメインのメールをGoogle Workspaceへ集約するのか
・一部だけ既存メールサーバーに残すのか
・代表メールをグループにするのか
・ユーザーとして作るのか
・既存メールを移行するのか
・問い合わせフォームの送信設定を変更するのか
を整理する必要があります。
混在運用は、長期化すると分かりにくくなる
一時的な検証や移行期間であれば、複数の環境が混在することはあります。
しかし、恒久的に、
メインドメインはGoogle Workspace
一部メールはレンタルサーバー
一部メールはサブドメイン
一部ユーザーは無料Gmail
一部ユーザーはOutlook
一部メールは転送のみ
のような状態にすると、運用が複雑になります。
特に問題になりやすいのは、
・どのメールアドレスが正式な窓口なのか分からない
・メールがどこに届くのか分かりにくい
・送信元アドレスが統一されない
・問い合わせフォームの送信元が古いまま残る
・DNSやメール認証の確認箇所が増える
・担当者が変わったときに引き継ぎにくい
・トラブル時に原因特定に時間がかかる
といった点です。
そのため、テストや一時的な回避策として使う方法と、長期的な本番運用は分けて考える必要があります。
まとめ
Google Workspaceのグループメールは、個人のメールアドレスと同じものではありません。
グループメールは、複数人にメールを配信するための宛先です。
ユーザーアカウントは、ログインしてGmailやGoogle Driveなどを使うためのアカウントです。
エイリアスは、既存ユーザーに追加する別名アドレスです。
メール委任は、1つのメールボックスを複数人で操作するための仕組みです。
また、Google WorkspaceでGmailを使うには、ドメインの所有権確認やMXレコードの設定が関係します。
一部のメールだけレンタルサーバーに残す構成も理論上は考えられますが、Google Workspace側の分割配信は、MXレコードがGoogleを向き、Gmail側で処理したうえで別サーバーへ配送する前提があります。
そのため、日本のレンタルサーバーの内部配送や既存メール運用と組み合わせる場合は、慎重な設計が必要です。
テストドメインについても、単に「別の仮ドメインで本番の代わりに使う」という考え方ではなく、Google Workspaceの設定確認や試験運用のためのものとして理解する方が安全です。
基本的には、Google Workspaceへ移行する場合、利用しているメールアドレスを整理し、できるだけGoogle Workspace側へ集約する方が、長期的には管理しやすく、トラブルも少なくなります。
Google Workspaceのの申し込み
Google Workspaceの申し込みは、ここからできます。