Microsoft Entra ID（旧 Azure AD）でカスタムドメインを追加・確認（Verify）しようとした際に「Domain is being used by an active tenant」と出て進めない場合、原因はDNSではなく“別テナントに紐づいたまま”という状態です。この記事では、旧テナントからドメインを解放して現在のテナントで使えるようにする実務手順と注意点を整理します。
今回の症状：DNSのTXTを入れても確認できない
現在のテナント（Tenant ID: 021887c8-7cf4-4c34-a04f-e302446416e6）でカスタムドメイン paulsonsunny.com.au を追加し、表示されたTXTレコード（TXT Name: @ / TXT Value: MS=ms95854466）をDNSに設定しても、確認（Verify）時に次のエラーで失敗します。
Domain verification failed: “Domain is being used by an active tenant”
| 起きていること | よくある誤解 | 実際に必要な対応 |
|---|---|---|
| 新テナントでドメイン確認ができない | TXTが間違っている／DNS反映待ち | 別テナントに残っている「確認済みドメイン」登録を外す |
| エラーに“active tenant”と出る | 自分のテナントがアクティブではない？ | ドメインが別のテナントで利用中（＝排他的に保持） |
| DNSに正しいTXTを追加済み | それなら新テナントで勝てるはず | DNSは「所有の証明」にはなるが、旧テナントの紐付け解除にはならない |
なぜ起きる？「1つのドメイン = 1つのテナント」の排他仕様
Microsoft Entra ID（Azure AD）やMicrosoft 365で使うカスタムドメインは、同一ドメインを複数テナントに同時登録できない設計です。過去に別のAzure／Microsoft 365テナントに追加して“確認済み（Verified）”になっている場合、新しいテナントにTXTを入れても「他テナントで使用中」判定が優先され、確認が止まります。
つまり、解決の本質はシンプルで、旧テナント側でドメインを削除（または未確認状態に戻して切り離し）し、新テナントで改めてVerifyすることです。
最初に押さえるべき結論（最短ルート）
| パターン | できること | 最短での解決策 |
|---|---|---|
| 旧テナントに管理者として入れる | 自力で設定変更・削除が可能 | （必要ならFederated→Managed）→ 依存関係を外す → ドメイン削除 → 新テナントでVerify |
| 旧テナントに入れない（管理者不明／退職／契約終了など） | 自力では外せない | DNSで所有を証明し、Microsoft側に旧テナントからドメイン解放を依頼 |
作業前の重要注意：ドメイン削除は“影響範囲”が広い
ドメインを旧テナントから外す作業は、単に「一覧から削除」するだけでは済まないことがあります。特にMicrosoft 365（Exchange Online/Teams/SharePoint）も同じテナントで使っている場合、ドメインが次の用途で参照されていると削除できません。
| 参照されやすい場所 | 具体例 | 削除前にやること |
|---|---|---|
| ユーザーのサインイン名（UPN） | [email protected] | [email protected] に変更 |
| メールアドレス/プロキシアドレス | SMTP:[email protected] | 別ドメインへ付け替え、必要ならメール転送や一時アドレスを用意 |
| グループ/共有メールボックス | [email protected] | アドレス置換・削除、配送停止の影響確認 |
| アプリの識別子/リダイレクトURI | https://paulsonsunny.com.au/auth | 新ドメイン運用に合わせてアプリ登録を更新 |
| フェデレーション（AD FS等） | Federatedドメインとして構成 | 先にManagedへ戻す（これを飛ばすと削除が詰まりやすい） |
本番利用中のテナントからドメインを外す場合は、影響がユーザーのログインやメール配送に直結します。作業ウィンドウ（夜間・休日）、連絡、切り戻し手順（最悪の場合は一時的に onmicrosoft.com に戻す）まで含めて計画するのが安全です。
手順：旧テナントに入れる場合（自力でドメインを解放する）
1) 旧テナントでドメインの状態を確認する
旧テナント（アクセス可能なテナント）に管理者でサインインし、ドメイン一覧を確認します。
- Microsoft Entra 管理センター（旧 Azure AD）で「カスタムドメイン名」一覧を確認
- Microsoft 365 管理センターを併用している場合は、そこでのドメイン状態も確認
ここで paulsonsunny.com.au が「確認済み」となっていれば、新テナント側で“active tenant”エラーになる条件が揃っています。
2) ドメインがFederatedなら、先にManagedへ戻す
旧テナント側でドメインがフェデレーション（例：AD FS）として設定されていると、いきなりドメイン削除に進めないことがあります。まずは認証方式を Federated → Managed に戻します。今回のケースでは Microsoft Graph API を使って authenticationType を Managed に変更しています。
PATCH https://graph.microsoft.com/v1.0/domains/paulsonsunny.com.au
Content-Type: application/json
{
"authenticationType": "Managed"
}Graph APIを使う場合、実行アカウントにはテナント管理者権限に加えて、Graphの権限（例：Domain.ReadWrite.All 相当）が必要になります。運用上は、緊急時に備えて“ブレークグラス（緊急用）管理者”を用意しておくと詰まりにくいです。
PowerShellで実行したい場合は、Graph PowerShell から生のリクエストを投げる方法が確実です（コマンドレットの差異や更新の影響を受けにくい）。
# Microsoft Graph PowerShell（例）
# 事前に Microsoft.Graph モジュールを導入済みであること
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
$domain = "paulsonsunny.com.au"
$body = @{ authenticationType = "Managed" } | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH `
-Uri "https://graph.microsoft.com/v1.0/domains/$domain" `
-Body $body `
-ContentType "application/json"3) ドメインにぶら下がる“依存関係”を外す
ドメイン削除が失敗する最大の原因は、ユーザーやメールアドレスなどの参照が残っていることです。削除前に、次のような依存関係を外していきます。
| 対象 | チェック観点 | 実務での対処例 |
|---|---|---|
| ユーザー | UPNがカスタムドメインになっていないか | 一時的に onmicrosoft.com へ変更し、サインイン影響を案内 |
| Exchange（利用している場合） | 受信メールアドレス、共有メールボックス、配布グループ | 代替ドメインへ付け替え、送受信テスト、必要なら転送を設定 |
| Teams/SharePoint | 直接のドメイン依存は少ないが、サインイン名変更に連動 | サインインが変わってもユーザーは同一（オブジェクトID）であることを周知 |
| アプリ登録 | 返信URL、Identifier URI、SAMLのAudience/Reply | 新テナント移行前提で一時的に無効化／新URLへ差し替え |
「何が残っていて削除できないのか」が分からない場合は、管理センター側の削除画面で依存関係が表示されることがあります。表示された対象を一つずつ潰していくのが確実です。
4) 旧テナントからドメインを削除（または未確認状態へ）
依存関係を外したら、旧テナントのドメイン一覧から paulsonsunny.com.au を削除します。削除が成功すれば、ドメインは旧テナントの“排他ロック”から解放されます。
削除直後は、バックエンド反映により数分〜しばらく待つ必要があるように見える場合があります。DNSのTTLとは別に、Microsoft側の反映タイミングが絡むため、すぐに追加できないときは時間をおいて再試行します。
5) 新テナントでドメインを追加し、TXTでVerifyする
旧テナントから外れたら、現在のテナント（Tenant ID: 021887c8-7cf4-4c34-a04f-e302446416e6）で改めてドメインを追加します。新テナント側で表示されるTXT値と、DNSに入っている値が一致していることを確認してからVerifyしてください。
| 項目 | 今回の例 | チェックポイント |
|---|---|---|
| ドメイン | paulsonsunny.com.au | 末尾ドット有無など表記差は気にしなくてOK（DNS側で正しく設定されていることが重要） |
| TXT Name | @ | DNS事業者によっては「空欄」「ルート」「ドメイン名そのもの」を指定 |
| TXT Value | MS=ms95854466 | 前後の空白・引用符を付けない（事業者が自動で付ける場合もある） |
手順：旧テナントに入れない場合（Microsoft側に解放を依頼する）
旧テナントにサインインできない、管理者が不明、契約が切れて管理権限が戻せない、といった状況では、自力でドメインを外すことは基本的にできません。この場合は、DNSにTXTを入れたうえで「ドメインの所有者である」ことを示し、Microsoft側に旧テナントからの解放を依頼するのが現実的です。
無料のAzure開発者サブスクリプションなどで正式なサポートチケットが切れない場合でも、次のような窓口・経路が取れることがあります。
- Microsoft Q&A（公開フォーラム）での相談
- Microsoft 365 管理センターのサポート導線（契約状況によりチャット/電話が出る場合がある）
- ドメイン登録事業者（レジストラ）側の証明情報を添えて、サポートへエスカレーション
依頼前に準備しておくと通りやすい情報
| 準備物 | 具体例 | 意図 |
|---|---|---|
| 新テナント情報 | Tenant ID: 021887c8-7cf4-4c34-a04f-e302446416e6 | どのテナントへ移したいかを明確化 |
| ドメイン所有の証明 | TXT: MS=ms95854466 をDNSに設定済み | 第三者の乗っ取りではないことを示す |
| ドメインの経緯 | 過去に別テナントで利用していた可能性／現テナントに追加できない | サポート側が“旧テナント残存”を疑えるようにする |
| 影響の有無 | 旧テナントは現在運用していない、または運用不明 | 解放して良いかの判断材料（誤解放防止） |
問い合わせ文のたたき台（そのまま貼れる形）
実際のサポート窓口に送る文面は、情報が揃っているほど往復が減ります。以下をベースに、分かる範囲で追記してください。
件名：別テナントで使用中のカスタムドメイン解放依頼（Domain is being used by an active tenant）
ドメイン：paulsonsunny.com.au
現テナント（移行先）Tenant ID：021887c8-7cf4-4c34-a04f-e302446416e6
現テナントでドメイン追加・確認を行うと
"Domain verification failed: Domain is being used by an active tenant"
となり失敗します。
DNSには指定されたTXTレコード（MS=ms95854466）を設定済みで、ドメイン所有は証明可能です。
過去に別のAzure AD / Microsoft 365テナントで当該ドメインを登録していた可能性がありますが、
現在その旧テナントへ管理者としてアクセスできません。
旧テナント側から当該ドメインを解放し、現テナントで利用できるようにする手順（または解放作業）のご案内をお願いします。フェデレーション（Federated）ドメインが絡む場合の注意点
今回のように旧テナント側でドメインがフェデレーション構成になっていると、次の順番を守らないと詰まりやすいです。
- 先に Federated → Managed へ戻す（Graph APIで
authenticationTypeを更新） - 依存関係（UPN/メール/アプリ）を外す
- 最後にドメイン削除
フェデレーションをManagedに戻すと、サインインの動きが変わります。旧テナントがまだ利用されている可能性が少しでもある場合は、関係者と調整し、影響範囲を必ず確認してください。
TXTレコードが合っているのにVerifyできない時の落とし穴
「別テナント使用中」以外にも、DNSの設定ミスでVerifyに失敗することがあります。ドメイン解放後の再Verifyで詰まらないよう、以下もチェックしておくと確実です。
| 落とし穴 | ありがちな症状 | 対処 |
|---|---|---|
| DNSゾーンが複数ある | レジストラとCDN/ホスティングで二重管理 | 実際に権威DNSとなっているゾーンにTXTを入れる |
| TXT Name（@）の扱いが事業者で違う | @を入れたら @.paulsonsunny.com.au になってしまう | 「空欄」または「paulsonsunny.com.au」を指定するなど、事業者の仕様に合わせる |
| 値の前後に余計な文字が入る | 引用符を手で付けた／空白が入った | 値は MS=ms95854466 のみ（余計な文字を足さない） |
| 反映待ち（TTL/キャッシュ） | 外部から引けるまで時間差 | TXTが外部DNSで引けるか確認してからVerifyする（時間をおいて再試行） |
移行後に必ずやる確認（“追加できた”で終わらせない）
ドメインを新テナントで確認できたら、次は「安全に使える状態にする」フェーズです。特にMicrosoft 365を併用する場合、切り替え直後にトラブルが出やすいので、以下をチェックします。
- ユーザーUPNの変更方針（いつ、誰から、どのドメインにするか）
- メール送受信（MX/SPF/DKIM/DMARC）の整合性
- Teams/SharePointのサインインと権限
- SSOアプリ（SAML/OIDC）のリダイレクトURIや証明書更新
- 条件付きアクセスやMFA、サインインログの監視
再発防止の運用ヒント（“テナント迷子”を防ぐ）
ドメインがどのテナントに紐づいているか分からなくなる事故は、組織変更や外注、担当者交代で起きがちです。次の運用を入れるだけで、数年後の自分（または後任）が助かります。
- ドメイン追加時に「テナントID」「管理者連絡先」「契約情報」を台帳に残す
- ブレークグラス（緊急用）管理者を最低2アカウント用意し、MFA・保管方針も決める
- フェデレーション設定（AD FS等）を行ったら、設定値と変更手順をドキュメント化する
- 不要になったテナントは“放置”せず、ドメインやサブスクリプションを整理してからクローズする
今回のケースを手順に当てはめると
ポイントを今回の相談内容に沿って整理すると、やることは次の順番です。
- 新テナント側で要求されたTXT（
MS=ms95854466）がDNSに入っていることを確認 - Microsoft側の確認で、paulsonsunny.com.au が別テナントで「確認済み」になっている前提を押さえる
- 旧テナントに入れるなら、authenticationType を Managed に戻す → 依存関係を外す → ドメイン削除
- 旧テナントに入れないなら、TXTによる所有証明を添えて、Microsoftへ旧テナントからのドメイン解放を依頼
- 解放後、現在のテナント（Tenant ID: 021887c8-7cf4-4c34-a04f-e302446416e6）でVerifyをやり直す
「DNSを正しくしているのに進まない」時ほど、焦って設定をいじりがちです。しかし本件は、DNSよりもテナント間の紐付け（排他）が本丸です。旧テナント側の切り離しさえ完了すれば、新テナントでのVerifyは通るようになります。
コメント