Microsoft 365 を複数ドメイン（例：@domain1.com と @domain2.com）で運用していると、「個人メールボックスは統合できているのに、Microsoft 365 グループはどうすれば？」で詰まりがちです。ポイントは、グループに“受信先”をまとめるだけで良いのか、それとも“送信元アドレス”も複数で使いたいのか。要件を切り分けると、最短で迷わず設計できます。
まず結論：やりたいことを「受信」と「送信」で分けると最適解が決まる
Microsoft 365 グループは、グループ用メールボックス（会話）を持ち、宛先（To）に入ったメールを受け取ることができます。一方で、グループの仕様上、送信元（From）をエイリアスに切り替えて使う運用は得意ではありません。
| 要件 | おすすめ | 理由（ざっくり） |
|---|---|---|
| 2つのドメイン宛てメールを、同じグループ受信トレイに集約したい（受信が最優先） | Microsoft 365 グループにエイリアス追加 | 同一グループに複数アドレスを持たせ、どちら宛ても同じ受信先にできる |
| 送信元アドレスも domain1 / domain2 を切り替えて使いたい（受信＋送信） | 共有メールボックス | Send As（差出人）で複数アドレス運用がしやすい |
| Teams/Planner/SharePoint の連携も欲しい＋送信元も複数にしたい | Microsoft 365 グループ＋共有メールボックス併用 | コラボはグループ、メール運用は共有メールボックスで役割分担できる |
パターンA：Microsoft 365 グループに複数ドメインのエイリアスを付けて「受信」を集約する
「受信だけまとめたい」なら、この方法が最短です。1つの Microsoft 365 グループに、メインのアドレス（主アドレス）に加えて、別ドメインのアドレスをエイリアス（別名）として追加します。
この方法でできること／できないこと
| 項目 | できる | できない／注意が必要 |
|---|---|---|
| 受信の集約 | ◯（domain1 宛ても domain2 宛ても同じグループに届く） | — |
| グループからの送信（新規／返信） | ◯（グループとして送信できる） | 送信元は基本「主アドレス」固定になりやすい |
| 「[email protected] から送った」ように見せる | — | グループ単体では原則難しい（運用・代替案で吸収） |
| Teams/Planner/SharePoint 連携 | ◯（グループの強み） | — |
前提条件：ここが揃っていないとエイリアス追加はできない
- domain1.com と domain2.com が、同一 Microsoft 365 テナントで「確認済みドメイン」になっている
（管理センターの「設定」→「ドメイン」などで確認できる状態） - 追加したいアドレスが、他のユーザー／共有メールボックス／グループ／連絡先で使われていない
メールアドレスは基本的にテナント内で“一意”です。重複すると追加できません。 - 外部（社外）からも受け取りたい場合、グループが外部送信者からの受信を許可している
「社外から送ったのに届かない」は、ここが原因であることが多いです。
設定イメージ：主アドレス＋エイリアス
例えば、次のように設定します。
- 主アドレス（Primary）：
[email protected] - エイリアス（Alias / Proxy）：
[email protected]
この状態だと、[email protected] 宛ても [email protected] 宛ても、同じ Microsoft 365 グループの受信トレイに集約されます。
管理センターでエイリアスを追加する手順（画面操作）
管理センターの UI は更新されることがありますが、流れは概ね次の通りです。
- Microsoft 365 管理センターを開く
- 「チームとグループ」→「アクティブなチームとグループ」を開く
- 対象の Microsoft 365 グループを選択する
- メール関連の設定（メールアドレス編集・エイリアス追加 など）を開く
- ドメインのプルダウンで
domain2.comを選び、ローカル部（@より前）を入力して追加する - 必要に応じて「主アドレス」をどちらにするかも確認する
ポイントは「追加しただけで終わり」ではなく、主アドレスがどちらになっているかを必ず確認することです。返信や新規送信の From に影響します。
PowerShell でエイリアスを追加する手順（運用自動化にも向く）
PowerShell を使うと、複数グループへの一括設定や、Power Automate などと組み合わせた自動化がしやすくなります。一般的には Exchange Online PowerShell で Microsoft 365 グループ（Unified Group）を操作します。
例：現在のアドレスを確認
Connect-ExchangeOnline
# 対象グループのメールアドレスを確認（表示名や主アドレスも確認）
Get-UnifiedGroup -Identity "グループ名またはID" |
Format-List DisplayName,PrimarySmtpAddress,EmailAddresses例：エイリアス（別ドメイン）を追加（受信を集約）
# domain2 側のアドレスをエイリアスとして追加
Set-UnifiedGroup -Identity "グループ名またはID" `
-EmailAddresses @{Add="smtp:[email protected]"}例：主アドレスを切り替えたい場合（運用上重要）
Exchange 系のオブジェクトでは、SMTP:（大文字）が主アドレス、smtp:（小文字）がエイリアス扱いになることがあります。主アドレスを変える場合は、意図せず主が入れ替わらないように、全体のリストを明示して設定するのが安全です。
# 主アドレスを domain2 側にしたい例
Set-UnifiedGroup -Identity "グループ名またはID" `
-EmailAddresses "SMTP:[email protected]","smtp:[email protected]"例：作成時点から複数アドレスを持たせたい（新規作成）
# New-UnifiedGroup で作成し、EmailAddresses に複数指定する例（環境により指定方法が異なる場合があります）
New-UnifiedGroup -DisplayName "営業問い合わせ" -Alias "sales" `
-EmailAddresses "SMTP:[email protected]","smtp:[email protected]"PowerShell の指定方法は環境やモジュール更新で差異が出ることがあるため、まずはテストグループで確認し、意図した主アドレスになっているかを Get-UnifiedGroup で必ずチェックしてください。
制約：エイリアスは「受信」には効くが、「送信元の切り替え」には効きにくい
ここが導入後に揉めやすいポイントです。
- グループの返信・新規送信は主アドレス（例：[email protected]）から送られる
「domain2 宛に届いた問い合わせには domain2 の差出人で返したい」という要件があると、運用が破綻します。 - 相手は To で [email protected] を見ているのに、返信が [email protected] になる
取引先によっては「別会社・別窓口に変わった？」と誤解されることがあるため、事前に説明・テンプレ整備が重要です。 - “受信専用の別名”として割り切ると成功しやすい
例えば「受け口は複数ドメインで集約、返信は常に代表窓口（主アドレス）で統一」と決めると、トラブルが減ります。
運用で吸収するコツ（エイリアス受信の混乱を減らす）
- 主アドレスのポリシーを決める
「対外的な代表は domain1」「旧ドメインの domain2 は移行期間だけ受信」など、意味づけを明文化します。 - 署名・テンプレ・自動応答に“窓口の統一”を反映する
「このメールは代表窓口（[email protected]）から返信しています」など、1行あるだけで混乱が激減します。 - 外部送信者からの受信許可を忘れない
社外から届かないときは、まずここを疑います（特に導入直後）。 - 反映遅延を見込む
追加直後に「届かない！」となりがちです。反映に時間がかかる前提で、切り替え日時を設けると安全です。
パターンB：共有メールボックスで「受信」も「送信」も複数ドメインを使う
「[email protected] と [email protected] の両方を“送信元として”使いたい」なら、Microsoft 365 グループよりも、共有メールボックスの方が素直に要件を満たせます。
共有メールボックスが向いている理由
- 複数ドメインのメールアドレス（主＋エイリアス）を持てる
- Send As（差出人として送信）で、運用者が From を切り替えやすい
- 問い合わせ窓口や代表アドレスなど、メール運用が中心の用途と相性が良い
共有メールボックスの基本的な作り方（概念手順）
- 管理センター（Exchange / Microsoft 365）で共有メールボックスを作成する
- 共有メールボックスに
[email protected]を主アドレスとして割り当てる - 同じ共有メールボックスに
[email protected]をエイリアスとして追加する - 運用者（担当者）に対して、必要に応じて以下の権限を付与する
- Full Access（メールボックスを開ける）
- Send As（そのアドレスとして送信できる）
- Send on Behalf（代理送信として送る）
- Outlook で共有メールボックスを追加し、From を選択して送信する
共有メールボックス運用で押さえるべき注意点
| 注意点 | 内容 | 対策例 |
|---|---|---|
| コラボ機能が付いていない | Teams チーム、Planner、SharePoint サイトなどは自動的には付属しない | コラボが必要なら Microsoft 365 グループと併用する |
| 権限設計が必要 | 担当者の入替時に権限の付け外しが必要 | 運用手順書、棚卸し、申請フローを用意する |
| クライアント依存の挙動 | Outlook（PC/WEB/モバイル）で差出人選択の UI が異なる場合がある | 「標準操作」を1つ決めて周知（例：Outlook Web を基準にする） |
| 容量・ライセンス | 共有メールボックスの容量や機能は、条件によりライセンスが関わることがある | 長期保管・アーカイブ要件があるなら事前に設計する |
「グループの便利さ」も「送信元の柔軟さ」も欲しいときの現実的な併用パターン
現場の要件を詰めるほど、「受信はグループに集約したい（履歴・メンバー共有・Planner 連携など）」と「送信元はドメインごとに切り替えたい（取引先・ブランド・契約主体の都合）」が同時に出てくることがあります。その場合は、役割分担が現実的です。
併用パターン例
- コラボは Microsoft 365 グループ（Teams/Planner/SharePoint）
内部向けの議論、ファイル、タスク、意思決定はグループに集約。 - 対外メールは共有メールボックス（送信元切り替え）
問い合わせ対応や見積送付など、外部コミュニケーションは共有メールボックスで統一。 - 必要なら転送・CC 設計で“記録”をグループ側にも残す
共有メールボックスで受けたメールをグループにも共有したい場合、ルール設計で履歴を残す（ただし誤転送やループに注意）。
この構成は運用が少し増えますが、「やりたいことが M365 グループの強みとズレている部分」を無理にねじ込まないため、結果的にトラブルが減りやすいです。
代替案：目的によっては「グループ以外」の方がシンプルなこともある
「Microsoft 365 グループでやるべきか？」を再確認すると、実はもっと簡単に解決できる場合があります。
配布グループ（Distribution Group）で受信だけ集約する
- 複数ドメインのアドレスを持たせて、宛先を集約する用途に向く
- ただし、Microsoft 365 グループのような“グループ用受信トレイ（履歴）”や Teams/Planner 連携は目的外
- 「とにかく受信をまとめてメンバーへ配りたい」なら候補
メールフロールール（転送・リダイレクト）で集約する
- 「domain2 宛のメールを domain1 側へ寄せる」など、移行期間の暫定策として有効
- ルールを増やしすぎると、障害時の切り分けが難しくなる
- 意図しない転送（情報漏えい）やループに注意が必要
ドメインごとにグループを分ける（ブランド・契約主体が完全に別なら）
- 外向けの差出人・運用主体が違うなら、グループを分けた方が説明がシンプルになる
- ただし、メンバー管理・権限管理が増えるので、内部の運用コストと要相談
自動作成（Power Automate など）を絡めるときの設計ポイント
グループを自動作成している組織では、「作成と同時に [email protected] も付けたい」という要望がよく出ます。ここで重要なのは、作成フローの中で“どのレイヤーの設定を触る必要があるか”です。
考え方：グループ作成とメールアドレス設定は、管理対象が分かれやすい
- グループ作成は Microsoft 365 側（Microsoft Graph など）で実行できる
- 一方、メールアドレス（エイリアス／プロキシ）管理は Exchange Online 側の管理が絡むことが多い
- そのため、実務では「作成 →（必要なら少し待機）→ PowerShell/管理センターでエイリアス追加 → 検証」という二段構えが安定しやすい
運用に落とし込む例（設計の型）
| ステップ | 処理 | 失敗しやすいポイント | 対策 |
|---|---|---|---|
| 作成 | グループを作る（表示名・別名・オーナー設定など） | メールボックス側の準備がまだのタイミングがある | 作成直後の即時設定にこだわらず、後続処理で確実に適用する |
| 追加 | Exchange Online 側でエイリアスを付与 | 同名・重複アドレスで失敗 | 追加前に存在チェック（Get- 系）を入れる |
| 検証 | テストメール送信／メッセージトレースで確認 | 反映遅延で「届かない」と誤認 | 検証手順に待機や再確認を組み込む |
| 通知 | 運用者に利用開始案内 | 送信元制約を理解していない | 「受信は両方OK、送信は主アドレス」など要点をテンプレ化 |
よくあるトラブルと原因の切り分け（現場で役立つチェック表）
| 症状 | よくある原因 | 確認ポイント | 対応例 |
|---|---|---|---|
| [email protected] 宛に送ると「存在しない」エラーになる | エイリアスが未追加／誤字／反映前 | グループの EmailAddresses を確認 | 正しいエイリアスを追加し、反映後に再テスト |
| 社外から送ったメールだけ届かない | 外部送信者の受信がブロックされている | グループの外部受信許可設定 | 外部受信を許可、もしくは特定送信者のみ許可する設計へ |
| エイリアスを追加できない（重複エラー） | 別のユーザー／グループ／共有メールボックスが使用中 | 同一アドレスの利用状況 | 命名規則を見直す、または既存の割当を整理する |
| domain2 宛メールに返信したのに From が domain1 になる | グループは主アドレスで送信しがち | 主アドレス設定と運用要件 | 共有メールボックスへ切替、もしくは「代表窓口統一」として周知 |
| 関係者が「自分の受信トレイ」に見えないと言う | グループの会話は“グループ受信箱”に入る | Outlook のグループ表示、購読設定 | 「受信トレイに配信」設定や運用ルールの整理 |
導入前に決めておくと失敗しない「運用設計チェックリスト」
- 主アドレスはどちらのドメインにするか（返信・新規送信の見え方が変わる）
- エイリアスは何のために存在するか（移行期間なのか、恒久的な複数ブランドなのか）
- 外部（社外）からの受信を許可するか（許可するなら条件・例外・監査も）
- 送信元を切り替えたい要件があるか（あるなら共有メールボックスを前提にする）
- 問い合わせ対応の責任分界点（誰が見て、誰が返信し、誰が締めるか）
- 命名規則（ローカル部の一貫性：例 sales / info / support など）
- 変更・棚卸しの手順（担当者変更、権限の付け外し、不要エイリアスの整理）
まとめ：最短でうまくいく選び方
2ドメイン宛てメールを「同じグループで受けたい」だけなら、Microsoft 365 グループにエイリアスを追加するのが最短です。一方、「差出人もドメインごとに切り替えて送信したい」なら、共有メールボックスの方が要件に合います。コラボ機能まで含めて両方欲しいときは、グループと共有メールボックスの併用で“役割分担”するのが現実的です。
最初に要件を「受信」と「送信」で分け、主アドレス運用のルールまで決めてから設定に入ると、導入後の混乱を大きく減らせます。
コメント