Microsoft 365（M365／旧Office 365）で親ドメイン（例：contoso.com）を確認済みでも、サブドメイン（例：mail.contoso.com）を追加するときは「所有確認（ドメインの検証）」と「サービス利用のためのDNS設定」を分けて考えるのが近道です。この記事では、確認ステップが省略される条件と、Exchange Onlineでサブドメインのメールを安全に運用するためのDNSレコード設定・管理画面の手順を、具体例つきで整理します。
まず押さえるべき結論：検証が省略されても、DNS設定は別物
親ドメインがすでにMicrosoft 365（正確にはMicrosoft Entra ID／同一テナント）で確認済みの場合、同じテナントにサブドメインを追加すると「所有確認（TXTなどでの検証）」は自動的に完了するケースがあります。ところが、メールや各サービスを実際に使うためのDNSレコード（MX / SPF / Autodiscover / DKIM / DMARCなど）は、検証とは別工程であり、追加して終わりにはなりません。
| 区分 | 目的 | 代表的なDNSレコード | 親ドメイン確認済みなら省略できる？ |
|---|---|---|---|
| 所有確認（ドメイン検証） | 「そのドメインをテナントに登録してよい」ことの証明 | TXT（MS=msXXXX）または検証用MX | 同一テナント内でのサブドメイン追加なら自動検証されることがある |
| サービス利用のDNS設定 | メール配送・クライアント自動設定・送信ドメイン認証などの実運用 | MX / SPF(TXT) / Autodiscover(CNAME) / DKIM(CNAME) / DMARC(TXT) | 省略不可（使いたい機能が動かない） |
サブドメインの「所有確認」が省略される条件と例外
「親ドメインが確認済み＝サブドメインも無条件でOK」と覚えると、テナント間の取り合いや委任設定の落とし穴にハマります。ここでは、公式ドキュメントの記述に沿って条件を整理します。
同じテナントに追加する場合：サブドメインは自動検証される
Microsoft Entra IDのドメイン管理では、ルートドメイン（contoso.com）を先に追加・確認している場合、サブドメイン（europe.contoso.com等）は自動的に検証される旨が明記されています。Microsoft 365管理センターでサブドメインを追加した際に、検証ステップがスキップ（または追加後すぐ「確認済み」表示）になるのはこの挙動と整合します。
別のテナントに追加する場合：TXTレコードでの検証を求められる
一方で、contoso.comがすでに別のMicrosoft 365組織（別テナント）に追加されている状態でも、そのサブドメイン（xyz.contoso.com）を別組織に追加できるケースがあり、その場合はDNSホスティング側にTXTレコード追加を求められます。つまり「親ドメインの確認＝サブドメインの権利がテナント全体で固定される」わけではありません。
もしサブドメイン追加時にTXT検証を求められたら
管理センターの表示どおりに、サブドメイン用のTXT（MS=msXXXX）レコードをDNSに追加して検証します。TXTでの検証が難しい場合は、検証用のMXで代替できる場合もあります（ただし、検証用MXは既存メール配送に影響し得るため、検証が終わったら速やかに削除するのが安全です）。DNS反映は短時間で終わることもありますが、一般に数十分〜場合によってはそれ以上かかることがあります。
実務的な注意：サブドメインを外部へ委任しているなら“誰がDNSを持つか”がすべて
サブドメインをNSレコードで別のDNSゾーンに委任している場合、サブドメインのDNSを操作できる主体が変わります。サブドメインをMicrosoft 365に追加してメール運用したいなら、少なくとも「サブドメインのDNSゾーンにTXT/MX/CNAMEを追加できる権限」が必要です。委任先がベンダーや別部署なら、事前に運用ルール（誰がどのレコードを管理するか）を固めておくと後工程がスムーズです。
Microsoft 365管理センターでサブドメインを追加する手順
操作の流れはシンプルですが、サブドメインの場合は「検証が自動で終わったのに、セットアップが未完了に見える」ことがよくあります。これは後述のとおり、サービス用DNSが未設定だからです。
| 手順 | 操作場所 | やること | ポイント |
|---|---|---|---|
| 追加 | Microsoft 365管理センター | 設定 > ドメイン からサブドメインを追加 | 親ドメインが同一テナントで確認済みなら、サブドメインの検証は自動化されることがある |
| 利用サービス選択 | ドメインセットアップ | Exchangeなど利用するサービスを選ぶ | 「後で設定する（スキップ）」は可能でも、運用にはDNS設定が結局必要 |
| DNS設定 | DNSホスティング | MX/SPF/Autodiscover/DKIM/DMARC等を設定 | 値はテナントにより異なるため、管理センターの指示や表示値をそのまま使う |
なお、所有確認に使うTXT（MS=msXXXX）レコードは、既存のメールやWebサイトに影響しない形で追加でき、検証後は削除してよい旨が案内されています（ただし、監査やトラブルシュートの都合で一定期間残す運用もよくあります）。
「DNS設定をスキップできるか？」に対する実務的な答え
管理画面のウィザード上は「後で設定する」「手動で設定する」を選べるため、手続きとしてはDNS設定を後回しにできます。しかし、スキップできるのは“ウィザードの進行”だけで、メール配送や自動設定など“機能そのもの”はスキップできません。
たとえば、サブドメイン宛の受信メールをExchange Onlineに届けるには、そのサブドメインのMXレコードがExchange Onlineの宛先を指している必要があります。MXが未設定のままだと、インターネット上の送信元は配送先を決められず、当然メールは届きません。逆に言えば、受信をまだ切り替えたくない段階なら、MXを触らずに“アドレスを先に作る”こともできます（ただし、その間は外部受信はできません）。
Exchange Onlineでサブドメインのメールを使う全体像
サブドメインでメールを使う場合、よくある目的は次の2パターンです。
- アドレス体系を分けたい（例：[email protected]、採用は[email protected]、請求は[email protected]）
- 外部送信サービスの影響を分離したい（例：マーケ配信はmarketing.contoso.comに分離して評判低下を本体に波及させない）
後者はMicrosoftのメール認証ガイダンスでも、外部サービス（バルク配信等）を使うならメインドメインではなくサブドメインを推奨する考え方として言及されています。
構成をざっくり図示すると、次の関係になります。
（インターネットの送信元）
↓ MX参照
mail.contoso.com のMX → <MX token>.mail.protection.outlook.com
↓
（Exchange Onlineで受信）→ 受信ドメイン（Accepted domain）として扱う
↓
対象メールボックス/共有メールボックスに配信
Microsoft 365側でやること：受信ドメイン（Accepted domain）とアドレス付与
受信ドメイン（Accepted domain）の考え方
Microsoft 365にドメインを追加するとExchange Online側では「Accepted domain」として扱われ、ユーザーが送受信できるドメインになります。Accepted domainには主に2種類があり、一般的なクラウド完結運用では「Authoritative（権威）」を使うケースが多いです。
- Authoritative：そのドメインの受信者はMicrosoft 365側に存在する前提。存在しない宛先は拒否される。
- Internal relay：受信者がMicrosoft 365側にいなくても、別のメールサーバーへリレーされうる（ハイブリッド等向け）。
サブドメインを「全部Microsoft 365で完結させる（オンプレへ逃がさない）」のであれば、基本はAuthoritativeで考えるとトラブルが少ないです。
Exchange管理センターで確認しておくポイント
- Exchange管理センター（EAC）> メールフロー > 受信ドメイン で、追加したサブドメインが表示されるか
- 表示されている場合、ドメイン種別が意図（通常はAuthoritative）どおりか
「ドメインを追加したのに受信できない」相談の多くは、DNS（特にMX）未設定か、受信者（メールボックス/メールユーザー）がまだ作られていない・アドレスが付いていないケースです。Authoritative運用では、存在しない宛先は拒否される点も意識しておくと事故が減ります。
共有メールボックスをサブドメインで作る例
例として、共有メールボックス「[email protected]」を作りたい場合の流れです。
- Microsoft 365管理センターで共有メールボックスを作成（または既存共有メールボックスにエイリアスを追加）
- メールアドレスを「[email protected]」に設定
- 利用者に「フルアクセス」「送信元として送信」など必要な権限を付与
この時点では“アドレスとして”は設定できますが、DNSが未設定なら外部からの受信はできません。先にDNSまで通してから利用部門へ引き渡すと、問い合わせが減ります。
DNSホスティング側で設定すべきレコード：最低限と推奨を分けて考える
「メールが届く」だけならMXが最重要ですが、現実には迷惑メール対策や到達率のためにSPF/DKIM/DMARCまでセットで整えるのが前提になりつつあります。特にサブドメインは用途分離に使われることが多いので、送信ドメイン認証もサブドメイン単位で設計します。
| レコード | 名前（ホスト）例 | 値（ターゲット）例 | 目的 | 必須度 |
|---|---|---|---|---|
| MX | mail.contoso.com（DNS画面では「mail」や「@」の指定になることも） | <MX token>.mail.protection.outlook.com | サブドメイン宛メールの配送先をExchange Onlineにする | 受信するなら必須 |
| TXT（SPF） | mail.contoso.com | v=spf1 include:spf.protection.outlook.com -all | Microsoft 365を正当な送信元として宣言し、なりすましを抑止 | 送信するなら必須級 |
| CNAME（Autodiscover） | autodiscover.mail.contoso.com | autodiscover.outlook.com | Outlook等のクライアント自動設定を安定させる | 推奨（実質必須に近い） |
| CNAME（DKIM） | selector1._domainkey.mail.contoso.com selector2._domainkey.mail.contoso.com | （管理画面に表示される値をそのまま設定） | 送信メールにDKIM署名を付け、DMARC整合性も取りやすくする | 推奨（到達率に影響） |
| TXT（DMARC） | _dmarc.mail.contoso.com | 例：v=DMARC1; p=none; rua=mailto:[email protected] | SPF/DKIMの失敗時の扱いを宣言し、レポートで可視化する | 推奨（段階的に強化） |
DNS入力例：多くのレジストラ画面での書き方
実際のDNS管理画面は「名前（ホスト）」欄の扱いがバラバラなので、イメージしやすいように“よくある入力例”を載せます。あなたのDNSプロバイダーがFQDN入力型か相対名入力型かを確認し、二重に付けないよう注意してください。
| レコード種別 | ホスト欄（例） | 値欄（例） | 補足 |
|---|---|---|---|
| CNAME（Autodiscover） | autodiscover.mail | autodiscover.outlook.com | 「autodiscover.mail.contoso.com」を作りたい意図。画面によっては「autodiscover.mail.contoso.com」と全部入れる。 |
| MX | <MX token>.mail.protection.outlook.com | 優先度（Priority）は“数値が小さいほど優先”の画面が一般的。既存MXと共存させる期間は意図を明確に。 | |
| TXT（SPF） | v=spf1 include:spf.protection.outlook.com -all | SPFは1ドメイン（サブドメイン）につき1本。複数作らない。 |
MXレコード：サブドメインの“行き先”を決める
Microsoft 365（Exchange Online）のMXは、<MX token>.mail.protection.outlook.com という形式になります。トークンはテナントごとに異なるため、必ず管理センターが提示する値を採用してください。切り替え時は「今後どのメールがどこへ届くべきか」を整理した上で、古いMXの削除や優先度の調整を行います。
SPF（TXT）：サブドメインにも“1レコード”で定義する
SPFはドメイン（サブドメイン含む）ごとに定義し、同一ドメイン内に複数のSPF TXTレコードを作ると判定が崩れます。Microsoft 365のみで送信するなら、include:spf.protection.outlook.com を含めた形が基本になります。オンプレや外部配信サービスも併用するなら、includeやip4/ip6を統合して「1本のSPF」にまとめるのが鉄則です。
また、サブドメインで送信するなら、そのサブドメイン用のSPFが必要です。親ドメインのSPFがあるからといってサブドメインの送信認証が自動で満たされるわけではありません。
DKIM（CNAME）：2025年以降は“新形式”もあるので、表示値を鵜呑みにする
DKIMは「selector1」「selector2」という2本のCNAMEを作るのが基本です。Microsoft 365では、カスタムドメインやサブドメインでDKIMを有効化すると2つの鍵ペアが生成され、DNS上のCNAMEが公開鍵の参照先になります。重要なのが、2025年5月以降に導入された新しいCNAME形式です。従来の “…onmicrosoft.com” 形式のままのドメインもあれば、動的文字（例：n/r）を含む “…-v1.dkim.mail.microsoft” 形式が提示されるドメインもあります。両形式は混在できないため、管理画面（またはPowerShell）に表示された値をそのまま設定してください。
なお、サブドメインをFromアドレスとして使うなら、そのサブドメインごとにDKIM設定が必要です（メインドメインのDKIM設定がサブドメインに自動適用されるわけではありません）。
DKIMのCNAMEを追加してからMicrosoft 365が検出するまで、数分で終わることもあれば、環境によっては時間がかかる可能性があります。焦ってレコードを削除・再作成すると状況が悪化しやすいので、まずはDNSが外部から正しく引けているかを確認するのがコツです。
DMARC（TXT）：最初はp=noneで可視化→段階的に強化
DMARCは、SPF/DKIMの結果を使って「Fromのドメインが正当か」を判定し、失敗時の扱い（none/quarantine/reject）を受信側に伝えます。Microsoftは、DMARC設定の前提として、送信に使うカスタムドメイン／サブドメインのSPFとDKIMを整備してから進める手順を示しています。いきなりrejectにせず、まずはp=noneでレポート（rua）を収集し、問題がないことを確認してから強化すると安全です。
Autodiscover（CNAME）：サブドメインのメールアドレスほど効いてくる
Microsoft 365のメールでは、Autodiscover / MX / SPFが主要レコードとして案内されています。ユーザーが[email protected]で利用するなら、autodiscover.mail.contoso.com を素直に用意しておくのが安定策です（CNAMEでautodiscover.outlook.comへ）。「親ドメイン側のAutodiscoverがあるから大丈夫」と考えて動く場合もありますが、端末や環境差でハマりやすいので、アドレスとして使うドメインごとに用意するのが無難です。
DNS設定で一番多い事故：ホスト名の指定ミス（@ / mail / FQDN問題）
DNSレコードの入力UIはプロバイダーによって表記が異なります。特にサブドメインだと、同じことをしたつもりでも以下のようなミスが頻発します。
- 「mail.contoso.com」のゾーンでMXを作るべきなのに、親ゾーン（contoso.com）に「mail」を付けて作ってしまう
- ホスト欄にFQDN（mail.contoso.com）を入れるべき画面で「mail」だけ入れてしまい、mail.mail.contoso.com ができる
- 逆に、ホスト欄が相対名（mail）の画面でFQDNを入れてしまい、意図しないレコード名になる
不安なときは、設定後に必ず外部から名前解決を確認します。Windowsならnslookup、macOS/Linuxならdigが手軽です。
nslookup -type=mx mail.contoso.com nslookup -type=txt mail.contoso.com nslookup -type=cname autodiscover.mail.contoso.com
“スキップできない”をもう少し噛み砕く：やりたいこと別チェックリスト
| やりたいこと | Microsoft 365側の設定 | DNS側の設定 | スキップすると起きること |
|---|---|---|---|
| サブドメイン宛に外部からメールを受信したい | ドメイン追加／受信ドメインとして有効 | MX（必須） | そもそも届かない |
| サブドメインFromで外部へメール送信したい | 送信アドレス（プロキシアドレス）付与 | SPF（必須級）、DKIM（推奨）、DMARC（推奨） | 迷惑メール扱い、なりすまし対策に弱い |
| Outlookを自動設定で楽に使わせたい | 特になし（Exchange Onlineが応答） | Autodiscover CNAME（推奨） | 自動設定が失敗し、手動設定が必要になることがある |
大量のサブドメインを扱うなら：Exchange Onlineの「すべてのサブドメインを受信」も選択肢
プロジェクトやブランド単位でサブドメインが増え続ける場合、「サブドメインごとにドメイン追加・DNS作成」を繰り返すのは運用負荷になります。Exchange Onlineには、Accepted domainで「すべてのサブドメインを受信（match subdomains）」する設定があります。
ただし、この機能はAccepted domainをInternal relayにすることが前提で、未知の受信者を別経路へリレーする設計と相性が強い機能です。クラウド完結で全受信者がMicrosoft 365内にいる場合は、基本のAuthoritativeの方が安全で分かりやすいので、採用前にメールフロー設計（未知宛先をどうするか）を必ず検討してください。
まとめ：親ドメイン確認済みでも、サブドメイン運用はDNS設計で差がつく
- 同一テナント内で親ドメインが確認済みなら、サブドメインは自動検証されることがある。ただし別テナントではTXT検証を求められるケースもある。
- 所有確認が省略されても、Exchange Onlineでメールを使うためのDNS（MX/SPF/Autodiscover/DKIM/DMARC）は別途必要で、機能面ではスキップできない。
- サブドメインのメール運用は「受信（MX）」だけでなく「送信ドメイン認証（SPF/DKIM/DMARC）」まで整えると、到達率とセキュリティが安定する。
- DKIMは2025年以降に新形式が導入されているため、管理画面で提示されたCNAME値をそのまま使うのが安全。
コメント