Microsoft 365 をトライアルで試したあと解約すると、当時追加した独自ドメインが「解約済みトライアル テナント」に残り、有償（購入済み）テナント側でドメイン追加／認証ができないことがあります。さらに旧テナントへは MFA（Microsoft Authenticator）で入れず、ドメインを外せないケースも。この記事では、状況の切り分けから、Admin Takeover の可否判断、サポート チケットでのドメイン解放までを実務目線で整理します。
起きていることの正体：ドメインは「テナント間で同時に使えない」
Microsoft 365（Microsoft Entra ID）では、独自ドメイン（例：example.co.jp）は1つのテナントにしか紐づけられません。トライアルを解約しても、テナント自体がすぐに消えるわけではなく、ドメインの関連付け（検証済み状態）が残り続けることがあります。その結果、有償テナントでドメインを追加しようとしても「別の組織（別テナント）に追加済み」と判定され、認証（Verify）の先へ進めません。
また、Microsoft 側の仕様として、そのドメインを保持しているテナントの管理者が誰かは開示されません。自社が昔作ったトライアル テナントでも、連絡先や MFA が失われていると「どのアカウントで作ったか分からない」「入れない」という詰み方をします。
最短でゴールに行くための全体像
| 状況 | 自力解決の可否 | 最短ルート | ポイント |
|---|---|---|---|
| ドメインが「未管理（unmanaged／シャドウ）テナント」にある | 可能 | Admin Takeover（内部テイクオーバー）→旧側でドメイン削除→新側で追加 | TXT で所有権証明できれば進みやすい |
| ドメインが「管理済み（managed）テナント」にある（例：過去の M365 トライアル） | 難しい | 旧テナントに入ってドメイン削除 / 入れないなら有償テナントからサポート起票 | 管理済みはポータルだけで強制移管できないことがある |
| 旧テナントへ MFA（Authenticator）で入れない、管理者が1人だけ | 基本不可 | サポートへ「MFA 復旧」「ドメイン解放」を依頼 | DNS での所有権証明準備が重要 |
最初にやるべき切り分けチェック
この問題は、闇雲に操作しても遠回りになりがちです。以下のチェックを先に揃えると、Admin Takeover の可否判断も、サポートへの説明も一気に楽になります。
チェック項目（実務用）
- DNS を編集できるか（TXT レコードを追加できるか）
- ドメインのレジストラ／DNS ホスティングがどこか（社内でログイン情報が管理されているか）
- 有償テナントでドメイン追加を試したときのエラーメッセージ全文（表示される
xxxxx.onmicrosoft.comを控える） - 旧トライアル テナントの管理者サインイン情報が残っているか（メール・電話・バックアップコード等）
エラーメッセージから分かること
| 表示されがちな文言 | 意味（ざっくり） | 次にやること |
|---|---|---|
| 「このドメインは別の Microsoft 365 組織に追加されています（xxxxx.onmicrosoft.com）」 | ドメインが別テナントに保持されている | 旧テナントで削除 or サポートで解放 |
| 「所有は確認できたが追加できない（すでに別の組織に追加済み）」 | DNS 所有は証明できたが、移管は自動では進まない | サポートに「所有証明済み」を添えて起票 |
| 「Domain already managed in a tenant」など | 未管理テナントのテイクオーバー対象ではない可能性 | 管理済みとして旧テナント削除 or サポート |
パターンA：未管理（unmanaged／シャドウ）テナントなら Admin Takeover が効く
まず知っておきたいのは、Microsoft 365 の世界には「管理者が存在しない未管理テナント（unmanaged / shadow）」ができることがある、という点です。Power BI などのセルフサービス サインアップがきっかけで、組織のドメインで勝手に“影のテナント”が作られてしまうケースがあります。こうした未管理テナントであれば、Admin Takeover（管理者によるテイクオーバー）で自社が管理者になれる可能性があります。
内部（Internal）テイクオーバーの概要
Microsoft の手順では、Power BI のサインアップを起点に「Become the Admin（管理者になる）」ウィザードへ誘導され、DNS の TXT レコードで所有権を証明して管理者権限を得ます。ここでの重要ポイントは、“別テナントへ勝手に移行される”のではなく、まず未管理テナント側の管理者になることです。管理者になれたら、未管理テナントからドメインを削除して、有償テナントへ追加します。
内部テイクオーバーの手順（イメージ）
- 対象ドメインのメールを受け取れるアドレス（例：
[email protected]）で Power BI などにサインアップ（既に存在するならサインイン） - メールで届く確認コードでメールアドレスを検証
admin.cloud.microsoft（または Microsoft 365 管理センター）に移動し、表示される「管理者になる」ウィザードへ進む- 指示された TXT レコードを DNS に追加し、所有権を証明
- 未管理テナントの管理者になれたら、未管理テナント側でドメインを削除
- 有償テナントに戻ってドメイン追加・認証を実施
内部と外部の違い（混同しやすいので注意）
| 方式 | 何が起きるか | 向いているケース | 注意点 |
|---|---|---|---|
| 内部（Internal）テイクオーバー | 未管理テナント側で管理者になる（移行はしない） | まずは未管理テナントを掌握して、ドメイン削除したい | Microsoft 365（SharePoint/OneDrive を含む）では外部が使えないケースがある |
| 外部（External）テイクオーバー | 自テナントへドメインを移し、ユーザー等のマッピングも行う | Entra の“未管理”を自テナントへ統合したい | サービスによっては非対応。SharePoint/OneDrive を含むプランでは制限が出やすい |
パターンB：過去の「Microsoft 365 トライアル テナント」は多くが管理済み（managed）
ご質問の状況（2025年5月に Microsoft 365 を30日トライアル→解約→今回有償テナントで追加できない）は、実務上は管理済みテナントにドメインが残っているケースに当たりやすいです。管理済みの場合、未管理向けの Admin Takeover だけでは解決しないことがあります。
この場合のゴールはシンプルで、次のどちらかになります。
- 旧テナントにサインインできる：旧テナント側でドメインを削除してから、有償テナントで追加
- 旧テナントにサインインできない：Microsoft サポートに「ドメイン解放／移行」または「MFA 復旧」を依頼
旧テナントに入れるなら：ドメイン削除の“引っかかりポイント”を潰す
旧テナントに入れさえすれば、原則は「ドメインを参照しているものを全部外して削除」です。ただし、参照箇所が多いと UI で見落としが出ます。Microsoft のドキュメントでも、ユーザーやグループなど参照が多いほど削除に時間がかかる場合がある、と明記されています。
ドメイン削除の基本ステップ
- ユーザーのサインイン名（UPN）を
xxxxx.onmicrosoft.com側へ変更 - グループ／配布リストのプライマリ メールアドレスを
onmicrosoft.com側へ変更 - 必要に応じて DNS（MX など）を旧環境から切り替え（メールの流れを止める）
- 管理センターの「設定」→「ドメイン」で対象ドメインを削除
「削除できない」代表例
| 症状 | 原因 | 対処 |
|---|---|---|
| ドメインの削除ボタンが押せない | ユーザー／グループ／エイリアスなどがまだ参照 | 参照を外す（UI で漏れるなら PowerShell/Graph で棚卸し） |
| エラーが出て削除できない | エラー種別ごとの原因がある | エラー文言に対応した KB を確認し、参照を解消 |
| どうしても削除が進まない | 手動削除が必要なケース | サポートへエスカレーション |
MFA（Authenticator）で旧テナントに入れないとき：現実的な復旧ルート
「Authenticator を設定した覚えがないのにコード入力を要求される」「別の方法が出ない」「唯一の管理者で詰んだ」という状況は、現場でも珍しくありません。結論から言うと、自分で“完全に解除”する手段が無い状態に入っていることがあります。
まず試すべき“低コスト”手段
- サインイン画面で「別の方法でサインイン」が出るか確認（SMS、音声通話、別メールなど）
- 旧スマホが残っているなら、Authenticator のバックアップ／復元（端末・アプリの状態次第）
- 何度も失敗している場合は、追加試行を避ける（異常検知でブロックされることがある）
別の管理者がいるなら：管理者が MFA を“再登録要求”できる
もし旧テナントに別の管理者（グローバル管理者／認証管理者など）が存在するなら、その管理者が Entra 管理センターで「Require re-register MFA（MFA の再登録を要求）」を実行できます。これにより、次回サインイン時に MFA の再設定が促されます。
操作イメージ（管理者側）
- Entra 管理センター（
entra.microsoft.com）へサインイン - 「Users（ユーザー）」→対象ユーザー→「Authentication methods（認証方法）」
- 上部のアクションで「Require re-register MFA」を実行
唯一の管理者で完全ロックの場合：サポート（Data Protection など）の領域
旧トライアル テナントが「唯一の全体管理者が MFA で入れない」状態だと、第三者に悪用されないように設計されているため、ポータル操作だけで復旧するのは難しくなります。Microsoft の案内でも、端末紛失などでサインインできない場合は、IT 管理者（＝組織のヘルプデスク）に設定クリアを依頼する前提が示されています。自組織内でそれが不可能なら、サポートで本人確認のうえ対応を依頼する形になります。
有償テナント側でできること：ドメイン追加を“最後まで”進めて材料を揃える
「旧テナントに入れない」ケースでも、有償テナント側でやる価値が高いのがドメイン追加～TXT 検証まで進めることです。理由は2つあります。
- DNS を編集できる（＝所有者である）証拠を自分の手元に残せる
- サポートに渡すべきエラー文言や表示されるテナント情報（
xxxxx.onmicrosoft.comなど）が明確になる
管理センターでの手順（一般的な流れ）
- 有償テナントの管理者で Microsoft 365 管理センターへサインイン
- 「設定」→「ドメイン」→「ドメインの追加」
- 対象ドメインを入力し、検証方法として TXT レコードを選択
- 表示された TXT 値を DNS に追加
- 反映後に「確認（Verify）」
ここで、所有権は確認できても「すでに別の組織に追加済み」のため追加できない、という結果になる場合があります。その場合は“失敗”ではなく、サポートへ渡すべき決定的な材料が揃った状態です。
TXT レコード確認のコマンド（DNS 反映チェック用）
DNS の反映待ちで迷子になりやすいので、外形監視できるコマンドを1つ持っておくと便利です。
nslookup -type=txt example.com
# うまく見えない場合（DNSサーバーを指定して再確認）
nslookup -type=txt example.com 8.8.8.8TXT が見えないときは、DNS 側で「ホスト名（@ / 空欄）」「値（MS=xxxx など）」「重複 TXT（SPF と競合）」を見直します。特に SPF が既に TXT で入っている場合、DNS サービスによっては“別 TXT を追加できず統合が必要”なことがあるので注意してください。
結論：有償テナントからサポート チケット起票は「有効」どころか最優先
今回のようにドメインが別テナントに残っている／旧テナントに入れない（MFA で詰む）は、最終的に Microsoft 側の支援が必要になることがあります。そのため、有償テナントからサポート リクエスト（サービス要求）を起票するのは非常に有効です。
起票できる前提条件（見落としがち）
- Microsoft 365 のビジネス サブスクリプションの管理者であること
- 少なくとも1つは Microsoft から購入したサブスクリプションがあること（購入経路によってはパートナーへ連絡が必要）
起票場所（管理センター）
- Microsoft 365 管理センター右下の「ヘルプ & サポート」→検索→解決しなければヘッドセット（サポートに問い合わせ）
- または「サポート」→「新しいサービス要求」
サポートに書くべき内容（そのまま使えるテンプレ）
「短く書く」より「必要事項を漏らさない」ほうが解決が早いです。下記をコピペして、自社情報に置き換えてください。
件名：
独自ドメインが解約済みトライアル テナントに紐づいており、有償テナントで追加／認証できない
状況：
・2025年5月に Microsoft 365 をトライアル利用し、その後解約
・今回、有償の Microsoft 365 テナントを新規で用意（ユーザー数：15）
・有償テナント側で独自ドメイン（example.com）を追加しようとすると、
「ドメインは別の Microsoft 365 組織（xxxxx.onmicrosoft.com）に追加済み」
などの表示で先に進めない
・旧（トライアル）テナントは、サインイン時に Microsoft Authenticator の MFA を要求され、
Authenticator を設定した記憶がなくログインできない（解除不可）
依頼したいこと：
・旧テナント側に残っている独自ドメイン example.com を解放し、
有償テナントへ追加できるようにしてほしい
（または旧テナントの管理者アクセス復旧／MFA リセットの支援）
こちらで準備できること：
・DNS の TXT レコード追加によるドメイン所有権の証明は可能
・必要なら Microsoft から提示される検証用 TXT を追加できる
添付（可能なら）：
・有償テナントでドメイン追加時に表示されるエラーメッセージのスクリーンショット
・表示された xxxxx.onmicrosoft.com の値サポート対応をスムーズにする“必須の持ち物”
| 準備するもの | なぜ必要か | 具体例 |
|---|---|---|
| DNS 編集権限 | 所有権確認の根拠になる | TXT を追加できる |
| エラー全文 | どのテナントに紐づくかの手がかり | xxxxx.onmicrosoft.com |
| 有償テナントの情報 | サポートが対象環境を特定する | テナント名、管理者 UPN |
| 連絡先（電話・メール） | 本人確認／折り返し | 管理センターの連絡先 |
どうしても急ぐ場合の暫定運用：ドメイン解放まで“止まらない”方法
ドメインが解放されるまで何もできない、ということはありません。特に今回のように「15ユーザー分を購入済み」なら、先に環境を作っておくと後の切り替えが楽になります。
暫定運用の現実解
- ユーザー作成は
xxxxx.onmicrosoft.comで先に進める（Teams / OneDrive / Office アプリは使える） - ドメイン追加後に、ユーザーの UPN とメールアドレス（主 SMTP）を切り替える計画を立てる
- メールが最優先なら、現在のメール環境で転送を組み、切り替え日に MX を変更する
後でドメインを切り替えるときの注意
ドメインを追加できた後は、ユーザーのサインイン名（UPN）やメールアドレス変更が発生します。業務影響を減らすために、切り替え順序（管理者→少人数→全体）と、変更後のサインイン先（https://portal.office.com など）を周知する計画が重要です。
再発防止：トライアル利用の落とし穴を回避する運用ルール
今回のトラブルは「ドメインが残る」「管理者が1人」「MFA 復旧手段がない」が重なると起きやすいです。小規模でも以下を守ると再発率が一気に下がります。
| ルール | 狙い | 具体例 |
|---|---|---|
| 管理者を2名以上にする | 1人ロックアウトを防ぐ | 全体管理者＋認証管理者 |
| MFA の復旧手段を複数持つ | Authenticator だけの詰みを避ける | SMS/音声、別デバイス、復旧連絡先 |
| トライアル終了前に独自ドメインを外す | “解約済みテナントに残る”を防ぐ | 参照を外してドメイン削除 |
| テナント情報を保管する | 誰がどこを管理しているか迷わない | onmicrosoft.com、管理者 UPN、連絡先 |
よくある質問
解約したのに、なぜドメインが残るのですか？
サブスクリプションの解約＝テナント削除ではないためです。ドメインがテナント内のユーザーやグループなどで参照されている限り、テナント側に保持されます。
DNS の TXT で所有権を証明できたのに、追加できないのはなぜ？
「所有権の確認」と「テナント間の移管」は別物です。所有権は確認できても、既に管理済みテナントにドメインがある場合、セキュリティの都合で自動的に移管されないことがあります。
旧テナントの管理者が分からないと言われました。探す方法はありますか？
原則として、他テナントの管理者情報は開示されません。ドメインを保持しているテナントにアクセスできない場合は、DNS 所有権の証明を用意してサポートへ依頼する流れが現実的です。
電話が自動案内で繋がりません。オンライン起票だけで大丈夫？
まずは有償テナントの管理センターからオンラインでサービス要求を作成するのが基本ルートです。管理センター右下の「ヘルプ & サポート」からサポートに問い合わせる手順も案内されています。
MFA を設定した覚えがないのに Authenticator が要求されるのはなぜ？
組織のセキュリティ設定（既定のセキュリティ既定値、条件付きアクセスなど）や過去の登録状況により、意図せず MFA が必須になっていることがあります。端末紛失・機種変更で通知が受けられない場合は、管理者による設定クリアが必要になることがあります。
コメント