Microsoft 365 でカスタムドメインを追加しようとしたら「既に別のテナントで使用中」と表示され、所有確認（DNS 検証）すら進められない――このトラブルは、過去の設定や試用テナントの “置き土産” で起きがちです。本記事では、紐づき先テナント ID の確認方法から、管理者テイクオーバーの考え方、最終的に Microsoft サポートへ移管・解除を依頼する実務まで、再現性の高い手順で整理します。
現象の整理：何が起きていて、なぜ自分のテナントに追加できないのか
Microsoft 365（正確には Microsoft Entra ID / Azure AD のテナント）では、1つのカスタムドメインは同時に1つのテナントにしか「検証済み（Verified）」として紐づけられません。そのため、あなたが現在そのドメインの正当な所有者でも、ドメインが別テナントで検証済みのままだと、あなた側のテナントで次のような状態になります。
- ドメイン追加の画面で、所有確認（TXT 追加）に進む前にブロックされる
- 「このドメインは既に別の Microsoft 365 テナントで使用されています」等のエラーになる
- ドメインが紐づく先（テナント）を特定できても、あなたの権限では解除できない
ポイントは、ドメイン紐づけの解除は基本的に “現在そのドメインを持っているテナント側” の管理操作であり、第三者（あなた）が勝手に剥がせる設計ではない、という点です。だからこそ、最初に「どこに紐づいているか」と「自力で行けるルートがあるか」を切り分けます。
作業に入る前の安全確認：メール停止や DNS 事故を防ぐチェック
ドメイン取り戻し系の対応は、DNS を触る場面が必ず出ます。現状でメール運用中のドメインだと、手順を誤ると受信不能などの事故につながるため、まずは状況を固定化します。
| 確認項目 | 見る場所 | 目的 | 推奨アクション |
|---|---|---|---|
| DNS を自分が編集できるか | レジストラ / DNS ホスティング | 所有確認の前提 | ログイン可能・変更反映できる状態にする |
| MX が Microsoft 365 を向いているか | DNS の MX レコード | 現在 M365 メール運用中か推測 | 値を控える。必要なら TTL を短くする |
| SPF / DKIM / DMARC | TXT / CNAME | メール到達性の維持 | 現行値を退避（スクショ・メモ） |
| Autodiscover 等の CNAME | CNAME レコード | Outlook 接続の影響把握 | 変更前に控える |
この時点で、DNS の現行値は必ず控えてください。何かが起きても “元に戻す” という選択肢があるだけで、復旧が一気に簡単になります。
そのドメインが紐づいているテナント ID の調べ方
「どのテナントに取られているのか」を把握できると、サポート依頼時の説明が具体化し、対応が早くなることがあります。ここは、手元のブラウザだけで確認できる方法が実用的です。
フェデレーションメタデータ（XML）から確認する
次の URL にアクセスすると、フェデレーションメタデータ（XML）が表示され、entityID 付近にテナントを示す情報が含まれます。
https://login.microsoftonline.com/＜自分のドメイン名＞/FederationMetadata/2007-06/FederationMetadata.xml確認のコツ：
- XML 内の entityID やそれに類する識別子（GUID 形式の値）が手がかりになります
- ドメインが Microsoft 365 / Entra ID で使われている場合、このエンドポイントが参照できることが多いです
OpenID 構成（JSON）で “issuer” から把握する
XML より見やすいことがあるのがこちらです。ドメイン名を指定すると JSON が返り、issuer にテナント ID が含まれることがあります。
https://login.microsoftonline.com/＜自分のドメイン名＞/.well-known/openid-configuration表示された JSON の中で、次のような値を探します。
- issuer（例：
https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0） - authorization_endpoint などに含まれる GUID
プログラムで確認したい場合：Microsoft Graph という選択肢
環境によっては Microsoft Graph で、ドメイン名からテナント情報を引く API（例：findTenantInformationByDomainName）を利用して自動化できます。ただし、Graph 側の呼び出し条件（権限・認証方式）によっては手間が増えるため、まずは上記 URL を確認するだけで十分なケースが多いです。
なぜ「知らないテナント」にドメインが登録されるのか
正当な所有者としては納得しにくい現象ですが、現場では次のパターンが非常に多いです。
| よくある原因 | 起こる流れ | 見分けるヒント | 取り戻し方の方向性 |
|---|---|---|---|
| 過去の所有者が試用テナントで検証した | 試用中に DNS TXT を入れて検証 → テナントだけ残る | 社内に “昔触った人” の記憶がない | 旧管理者に削除依頼 / できなければサポート |
| 外部委託（制作会社/情シス代行/MSP）が登録した | 移行作業中に代行側テナントで検証 → 返却されない | DNS を触れるのは自社だが M365 管理者が不明 | 委託先にドメイン解除を依頼（最短） |
| ドメイン管理が一時的に他者へ渡っていた | レジストラ移管・ネームサーバ変更で一時的に検証される | 過去に移管/更新のトラブルがあった | 監査ログが取れないならサポート寄り |
| 社内で複数テナントが乱立している | 部署ごとに勝手にテナント作成 → どこかが先に検証 | 社内に複数の “管理者っぽい” アカウントがある | 社内調査 → 該当テナントで解除 |
重要なのは、「過去に DNS を編集できた誰かがいた」ということです。Microsoft 365 のドメイン検証は DNS を使うため、完全な第三者が偶然あなたのドメインを奪うのは現実的ではありません。大抵は、移行・試用・外注・引き継ぎ漏れのどれかです。
最短で解決するルート：前の管理者（旧テナント）にドメインを外してもらう
もし “誰が触ったか” に心当たりがあるなら、まずこれが最速です。旧テナントの管理者に依頼して、ドメインを削除してもらいます。
ただし、Microsoft 365 側ではドメインが以下に使われていると削除できません（旧管理者が「削除できない」と言う典型理由）。
- ユーザーのサインイン ID（UPN）に使われている
- Exchange のメールアドレス / エイリアスに残っている
- グループや共有メールボックスに紐づいている
- アプリやサービスで参照されている（まれに）
旧管理者への依頼文には、次の “作業の意図” を明記するとスムーズです。
- 対象ドメインを旧テナントから削除したい（解除したい）
- 削除に必要なら、ユーザー UPN やメールアドレスを一時的に
.onmicrosoft.comへ戻してよい - 削除できたら連絡がほしい（こちらで新テナントへ追加する）
自力でできる可能性がある対応：管理者テイクオーバー（admin takeover）
「旧管理者が誰か分からない」「連絡が付かない」場合でも、条件が合えば 管理者テイクオーバー で取り戻せることがあります。これは、Microsoft が用意している “ドメイン所有者が管理者権限を回収する” ための考え方です。
管理者テイクオーバーが効きやすいケース
- ドメインが、いわゆる “管理が行き届いていない状態のディレクトリ（テナント）” に紐づいている
- あなたが現在、DNS を編集できる（TXT を入れられる）
- 過去に作られた試用・自動作成のテナントで、実運用されていない可能性が高い
逆に、既に本格運用されている “管理済み” テナントに紐づいている場合、テイクオーバーだけでは完結しないことがあります。その場合はサポートへ進む判断が早いです。
管理者テイクオーバーの大まかな流れ（実務目線）
画面文言は時期によって変わることがありますが、やること自体はシンプルです。
- 対象ドメインを追加しようとしている（あなた側の）テナントを用意する
まだテナントがない場合は新規で用意します。 - ドメイン追加の途中で求められる DNS 検証（TXT 等）を実施する
「このドメインを管理しているのは自分」という事実を DNS で示します。 - 案内に従い、管理権を引き継ぐ（または紐づけ解除の方向へ進む）
条件が合えば “管理者として引き継ぐ” 導線が提示されます。
実務での注意点：
- DNS を変更したら、反映まで時間がかかることがあります（TTL に依存）。急ぐ場合は事前に TTL を短くしておくと有利です。
- 検証用 TXT を入れる際、既存の SPF（
v=spf1）など重要 TXT を上書きしないようにします。TXT は “追加” であり、置き換えないのが基本です。 - 本番運用中のメールがある場合、関係者に周知してメンテ時間を確保するのが安全です。
テイクオーバーで解決できないとき：Microsoft サポートに “ドメイン解除/移管” を依頼する
あなたのケースのように、
- メタデータ等で、見覚えのないテナント ID に紐づいていることは分かった
- 旧管理者が不明、またはテイクオーバーの導線が出ない / 進まない
- さらに、ライセンス未契約で管理センター導線が弱い
この条件が重なると、最終的には Microsoft 側の調整がほぼ必須になります。ここからは “サポートに通じる形” を作ることが解決の鍵です。
サポートへ出す前に準備しておくと強い証跡
サポートで話が早いのは、「あなたがドメインを今、正当に管理している」ことを客観的に示せる材料です。
| 準備物 | 例 | 役に立つ理由 |
|---|---|---|
| ドメイン所有を示す資料 | レジストラの管理画面スクショ、契約メール、請求書 | 正当な所有者であることの裏付け |
| WHOIS 情報 | 登録者/管理者情報、更新履歴 | 所有関係の説明に使える |
| DNS を管理できる証拠 | TXT を追加できる画面、反映確認 | “今この瞬間” の支配権を示せる |
| 紐づき先テナント ID | FederationMetadata / OpenID で得た GUID | サポートが対象を特定しやすい |
| エラー画面のスクショ | 「別テナントで使用中」等 | 現象説明が一発で伝わる |
ライセンス未契約でも進めるための現実的な考え方
結論から言うと、完全に無契約・無課金の状態で、第三者テナントに紐づくドメインを “強制的に剥がす” ところまで自力で到達できるケースは限られます。理由は単純で、テナント間の所有権争いになり得る操作は Microsoft 側の審査・調整が必要になり、その窓口がサポートだからです。
そこで現場では、次のどれかで “サポートに到達する導線” を作ることが多いです。
- 既に社内にある別の Microsoft 契約（Microsoft 365 / Azure 等）から問い合わせる
別契約の管理者がいる会社は、このルートが最短です。 - 新規テナントを作り、最小構成でサポートを起票できる状態にする
例えば必要最低限のサブスクリプションを持つことで、サポート窓口が現実的になります（費用最小化を狙う）。 - Microsoft パートナー（代行/販売店）経由で支援を受ける
自社に窓口がない場合、パートナーのサポート導線で前に進むことがあります。
「取り戻したいドメインが一つだけ」「すぐ使いたい」という状況ほど、時間コストが支配的になります。ライセンスを一時的に持つことは抵抗があるかもしれませんが、サポートに出せない状態で足踏みするより、結果として安く済むこともあります。
サポートへ伝えるべき要点（テンプレ）
サポート担当者に状況を最短で理解してもらうため、以下の要点を短くまとめて伝えます。
- 対象ドメイン：example.com
- 現象：Microsoft 365 でドメインを追加できず、「別テナントで使用中」と表示される
- あなたの立場：現在の正当な所有者であり、DNS を管理している（TXT を追加できる）
- 確認済み情報：FederationMetadata / OpenID などから確認した “紐づき先” のテナント ID
- 依頼内容：対象ドメインの紐づけ解除、または正当な所有者テナントへの移管
文章例（そのまま使えるように短くしています）：
対象ドメイン example.com を Microsoft 365 テナントに追加しようとすると「別テナントで使用中」と表示され追加できません。
当社は当該ドメインの正当な所有者で、DNS を管理しており、TXT 追加等の所有証明が可能です。
FederationMetadata / OpenID 構成から、当該ドメインが紐づくテナント ID は xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx と確認しました。
当社テナントで利用できるよう、当該ドメインの紐づけ解除または移管をご支援ください。判断を迷わせない：状況別のおすすめルート早見表
| 状況 | 最優先アクション | 次の一手 | ゴール |
|---|---|---|---|
| 旧管理者に心当たりがある | 旧テナントからドメイン削除を依頼 | 削除できない場合は “何に使われているか” を確認して外してもらう | あなたのテナントに追加 |
| 心当たりがないが DNS は自分で触れる | 管理者テイクオーバーの導線を試す | 進めない/失敗する場合はサポートへ | 解除または移管 |
| DNS を自分で編集できない | まず DNS 管理権限の回収 | レジストラ移管・ネームサーバ見直し | 所有証明可能な状態 |
| ライセンス未契約で窓口がない | サポートに到達する導線を確保 | 最小構成の契約/パートナー経由を検討 | Microsoft 側の調整へ |
つまずきやすい落とし穴と、回避のコツ
TXT レコードで SPF を壊してしまう
DNS 検証の TXT を追加する際に、既存の SPF（v=spf1）を上書きすると、メール到達性が一気に落ちることがあります。
- TXT は “置き換え” ではなく “追加” が原則
- 既存 TXT が多い場合は、ホスト名（@ / 空欄）をよく確認する
- 作業前に現行 TXT をバックアップする
ドメイン移行中に MX を先に変えてしまう
「早く Microsoft 365 を使いたい」気持ちで MX を先に切り替えると、ドメイン紐づけが完了していない時点では受信が不安定になります。先にやるべき順序は次の通りです。
- ドメインを新テナントへ追加（または移管/解除の完了）
- 必要な DNS レコードの整備（検証含む）
- 最後に MX 切り替え（段階的に）
テナント ID は分かったのに、連絡先が分からない
テナント ID が分かっても、そのテナントの管理者に直接連絡する手段がないことがほとんどです。ここは割り切って、
- 旧管理者に心当たりがないなら、テイクオーバーを試す
- それでもだめなら、サポートへ “解除/移管” を正式依頼する
という一本道にした方が、時間ロスが減ります。
よくある質問
ドメインが別テナントに紐づいているだけで、第三者にメールを読まれることはありますか？
ドメインが紐づいているだけで自動的にメールが盗み見されるわけではありません。メールの配送先は基本的に DNS（MX）で決まります。ただし、別テナント側が過去にメール運用していた形跡がある場合は、設定が残っている可能性もあるため、現行の MX / SPF / DMARC を点検し、不審な転送設定がないかなどを合わせて見ておくと安心です。
メタデータ URL が開けない／情報が取れません
ドメインの状態や構成によって、期待通りに情報が見えないことがあります。その場合は OpenID 構成（/.well-known/openid-configuration）も併用し、それでも難しければ「現在の紐づき先の特定」はサポートに委ねる方が早いこともあります。重要なのは、あなたが DNS を管理できる証拠を固めることです。
本当にライセンスなしで取り戻せますか？
条件が合えば、管理者テイクオーバーだけで進むケースはあります。ただし、相手側が管理済みテナントだったり、運用が残っていたりすると、第三者が自力で剥がすのは難しくなります。その場合は、サポート窓口に到達できる状態を作るのが現実解です。
まとめ：この問題の攻略は「特定 → 自力ルート確認 → サポートで決着」
- まず、フェデレーションメタデータや OpenID 構成で、ドメインが紐づくテナントの手がかり（テナント ID）を掴む
- 旧管理者に心当たりがあれば、旧テナントからドメインを外してもらうのが最短
- 心当たりがなければ、条件次第で管理者テイクオーバーを試す
- それでも解決しない、または無契約で窓口がないなら、証跡を揃えて Microsoft サポートへ解除/移管を依頼する
「自分のドメインなのに使えない」は焦りますが、論点を切り分けて順番に潰せば、再現性高く前進できます。特に、サポートに出すときは “DNS を管理している証拠” と “紐づき先の手がかり” が効きます。準備を固めて、最短でドメインを取り戻しましょう。
コメント