xxx.onmicrosoft.com のアドレスでメールを送受信する — ライセンスとメールボックスの仕組みを押さえる
Microsoft 365（旧 Office 365）のテナントを作ると、contoso.onmicrosoft.com のような既定のドメインが自動で払い出されます。そこに adele.vance@contoso.onmicrosoft.com のようなアカウントを作ってサインインはできるのに、いざそのアドレスでメールを受け取ろうとすると届かない、送ろうとしても Outlook が見当たらない、という状況にぶつかることがあります。
きっかけは検証用途が多いはずです。Azure のサインアップや Identity Validation の確認メール、外部サービスの登録確認など、テナント側のアカウントでメールを受信できる必要が出てくる。ところが onmicrosoft.com のアドレスは「アカウントはあるがメールボックスがない」状態で放置されがちです。この記事では、その理由と直し方を管理手順に沿って整理します。
onmicrosoft.com とは何のドメインか
onmicrosoft.com は、Microsoft Entra ID（旧 Azure Active Directory）のテナントを作成したときに自動で割り当てられる既定ドメインです。テナント名を接頭辞にして <テナント名>.onmicrosoft.com の形になり、独自ドメインを追加していなくても必ず 1 つ存在します。
このドメインは飾りではなく、実際にルーティング可能なメールドメインです。正式には MOERA（Microsoft Online Email Routing Address）と呼ばれ、独自ドメインを検証する前の初期セットアップや、独自ドメインとは別のバックアップ経路として使えます。つまり「onmicrosoft.com は本物のメールアドレスになり得る」という点がまず出発点です。
問題は、ドメインが本物であることと、あるアカウントがメールを送受信できることは別だという点にあります。
なぜ既定ではメールを送受信できないのか
ここが本記事の勘所です。サインインできることと、メールを送受信できることは、別々の仕組みに支えられています。
- サインインの主体は Entra ID の「ユーザーアカウント」です。ID とパスワード（および多要素認証）で本人確認し、テナント内のリソースへアクセスする権限を持ちます。
- メールを溜めて送受信するのは Exchange Online の「メールボックス」です。受信箱・送信済み・予定表などの実体はここにあります。
Entra ID のアカウントを作っただけでは、対応する Exchange Online のメールボックスは作られません。メールボックスは、そのユーザーに Exchange Online を含むライセンスを割り当てて初めて自動的に作成されます。ライセンスがないアカウントは、サインインはできてもメールの実体を持たないため、受信も送信もできないわけです。
flowchart LR
A["Entra ID<br/>ユーザーアカウント"] -->|サインインできる| B["テナント内リソース"]
A -.->|ライセンスなし| X["メールボックスなし<br/>= 送受信できない"]
A -->|Exchange Online<br/>ライセンス割り当て| C["Exchange Online<br/>メールボックス自動作成"]
C -->|送受信できる| D["メール"]
Azure の確認メールが届かなかったのは、アカウントの権限や設定の問題ではなく、そもそも受け皿となるメールボックスが存在しなかったから、というケースがほとんどです。
全体の流れは 3 ステップ
やることはシンプルで、次の 3 つです。
- メールボックスを持てるライセンスを用意する（購入する）
- 対象ユーザーにライセンスを割り当てる（メールボックスが自動作成される）
- Outlook on the web などでメールを送受信する
順に見ていきます。
手順 1: メールボックスを持てるライセンスを用意する
メールボックスの作成には Exchange Online を含むライセンスが必要です。既存のライセンスに空きがあればそれを使えますが、なければ購入します。単体で契約する場合は Exchange Online (Plan 1) が最小構成です。
Microsoft 365 管理センターの「マーケットプレース」から Exchange Online (Plan 1) を開くと、契約期間（1 か月・1 年・3 年）と請求頻度（月払い・年払い・3 年ごとの一括払い）の組み合わせで価格が決まります（2026 年 7 月時点、日本の標準価格）。
| 契約期間 | 請求頻度 | 価格 | 実質の月額 |
|---|---|---|---|
| 1 か月 | 月払い | ¥719 / ライセンス・月 | ¥719 |
| 1 年 | 月払い | ¥629 / ライセンス・月 | ¥629 |
| 1 年 | 年払い | ¥7,188 / ライセンス・年 | ¥599 |
| 3 年 | 3 年ごとに一括払い | ¥21,564 / ライセンス・3 年 | ¥599 |
同じ 1 年契約でも、請求頻度で単価が変わる点に注意します。月払いなら ¥629 / 月ですが、年払いにすると年 ¥7,188（実質 ¥599 / 月）となり、月払いより約 5% 安くなります。3 年契約を一括払いにした場合も実質 ¥599 / 月で、まとめて前払いするほど単価が下がる仕組みです。
メールを受信できればよいだけの検証用アカウントなら、この Plan 1 で十分です。50 GB のメールボックスと Outlook on the web が付き、独立したメール機能として最小のコストで済みます。大容量メールボックス・無制限アーカイブ・データ損失防止（DLP）などが必要になった段階で上位の Exchange Online (Plan 2) を検討すればよく、いきなり上位プランを選ぶ必要はありません。メール以外に Web 版 Office や Teams もまとめて必要なら、Microsoft 365 Business Basic のような Exchange Online を含む統合プランを選ぶ手もあります。
選び方はシンプルです。検証用途で使い終わりが見えているなら 1 か月契約の月払い（¥719 / 月）にしておき、不要になったら解約するのが無駄がありません。恒久的に使うなら、1 年契約の年払いや 3 年契約の一括払い（いずれも実質 ¥599 / 月）にすると、月払いより約 5% 安く抑えられます。
手順 2: ユーザーにライセンスを割り当てる
ライセンスを用意したら、対象ユーザーに割り当てます。
- Microsoft 365 管理センターにサインインする
- 「ユーザー」→「アクティブなユーザー」で対象アカウント（例:
adele.vance@contoso.onmicrosoft.com）を選ぶ - 「ライセンスとアプリ」タブを開き、Exchange Online (Plan 1) を含むライセンスにチェックを入れる
- 「変更の保存」を押す
ライセンスを割り当てると、対応するメールボックスプランをもとに Exchange Online のメールボックスが自動的に作成されます。反映には少し時間がかかり、Microsoft の案内では最大 15 分ほどでメールボックスと Outlook・予定表・連絡先が使えるようになるとされています。保存直後に Outlook が見当たらなくても、数分待ってから再確認してください。
手順 3: メールを送受信する
メールボックスができれば、あとは通常の Microsoft 365 アカウントと同じように使えます。もっとも手軽なのはブラウザだけで完結する Outlook on the web です。
- Outlook on the web に対象アカウントでサインインすれば、受信箱がそのまま使えます。追加のクライアント設定は不要です。
- デスクトップの Outlook やスマートフォンの Outlook アプリからも、同じアカウントでサインインすれば接続できます。
- 古い機器や独自のメールクライアントを使う場合は、IMAP / SMTP でも接続できます（テナントによっては既定で無効化されているため、Exchange 管理センターで対象メールボックスの認証プロトコルを有効化する必要があります）。
この時点で、Azure などからの確認メールを onmicrosoft.com のアドレスで受信できるようになっているはずです。
落とし穴: onmicrosoft.com からの外部宛て送信には上限がある
受信は問題ありませんが、onmicrosoft.com のアドレスから外部へ送信する場合は制限に注意が必要です。
Microsoft は onmicrosoft.com ドメインからの送信制限として、onmicrosoft.com ドメインからの外部宛て送信を、テナント単位で 24 時間あたり外部宛先 100 件までに制限しています。受信（インバウンド）には影響しませんが、上限を超えると外部宛ての送信が 550 5.7.236 の NDR（配信不能通知）で拒否されます。適用はテナントの規模に応じて段階的に進められ、2026 年前半までにすべての区分へ展開が完了しています。現在はほぼすべてのテナントが対象と考えてよいでしょう。
この制限の狙いは、onmicrosoft.com を本番の送信ドメインとして使い続けることを避けさせる点にあります。onmicrosoft.com はもともと送信レピュテーションを育てにくく、なりすましやフィッシングの温床にもなりやすいため、Microsoft は独自ドメインの利用を強く推奨しています。少量の確認メールや検証には支障ありませんが、業務メールや通知メールを継続的に外部へ送るなら、次のいずれかへ移すのが正解です。
- 独自ドメインを Microsoft 365 に追加し、既定の送信アドレスをそのドメインに変更する
- 大量送信や通知メールは Azure Communication Services など、送信専用の経路に分離する
実務上の勘所
整理すると、onmicrosoft.com のアドレスは次の使い分けがしやすくなります。
- 受信が目的（確認メール・通知の受け取り）なら、Plan 1 を割り当てるだけで十分に使える
- 少量の送信（返信・テスト送信）も問題ないが、外部宛ては 24 時間で 100 件という上限を意識する
- 業務での継続的な外部送信を担わせるドメインではない。独自ドメインを追加して主役を移す
検証環境のように「アカウントでメールを受け取れればよい」というニーズであれば、最小構成の Plan 1 を月払いで割り当て、用が済んだら解約する、という運用が最もコスト効率が良いでしょう。
まとめ
onmicrosoft.com のアドレスでメールを送受信できないのは、Entra ID のアカウントはあってもメールボックスがないからです。Exchange Online を含むライセンス（最小なら Plan 1）を割り当てればメールボックスが自動作成され、Outlook on the web ですぐに送受信できます。ただし外部宛ての送信は 24 時間で 100 件という上限がすでに適用されているため、受信や検証には使えても、本番の送信ドメインとしては独自ドメインへ移すのが前提だと理解しておくと、後から慌てずに済みます。