GoDaddyでTXTやMXを何度追加しても、Microsoft Entra ID（旧Azure AD）の「カスタム ドメイン」がいつまで経っても「確認できません」「別のディレクトリで使用されています」と言われる──Azure for Startups など複数テナントを触り始めたタイミングで、非常に起こりやすいトラブルです。本記事では、単なる「DNSの待ち」では解決しない、本質的な原因と、最短で復旧させるための実務的な手順をまとめます。
症状：GoDaddyでDNSを設定しても、Entra IDのドメイン検証が失敗する
この記事で扱う典型的な症状は次のようなものです。
- ドメインは GoDaddy で管理している
- Microsoft Entra ID（旧Azure AD）の「カスタム ドメイン名」で自社ドメインを追加した
- 表示された TXT または MX レコード を GoDaddy の DNS に追加した
nslookupや DNSチェックサイトではレコードが見える- それでも Entra ID 側の「確認」ボタンを押すとエラーになる
エラーメッセージの例：
- 「ドメインは別のディレクトリで使用されています」
- 「DNS レコードが見つかりません」
- 「このドメイン名は既に別の Microsoft Entra 組織で確認済みです」など
DNSを何度見直しても正しく見えるのに、Entra ID側だけが認めてくれない──このとき、原因はほぼ例外なく 別のところ にあります。
結論：原因の大半は「そのドメインが別テナントで既に“確認済み”」
Microsoft Entra ID では、同じカスタム ドメインを同時に複数テナントで「確認済み」にすることはできません。これは公式ドキュメントにも明記されており、あるテナントで既に検証済みのドメインは、別のテナントからは追加できません。
そのため、DNSにどれだけ正しいTXT/MXを入れても、
- そのドメインが 旧テナント（昔の検証環境、消したつもりのテナント、個人のM365テナントなど）でまだ「確認済み」のまま
である限り、新しいテナント（Azure for Startups用テナントなど）では絶対に「確認済み」になりません。
よくあるパターンを表にまとめると、次のようになります。
| 表側の現象 | DNSの状態 | 本当の原因 |
|---|---|---|
| TXTもMXも正しく見えるのに検証NG | GoDaddyに正しいレコードが載っている | 旧Entraテナントで既に「確認済み」 |
| 「別のディレクトリで使用されています」 | DNS自体は無関係 | ドメインが別テナントにひも付いている |
| 「DNSにレコードがありません」と言われる | 別のゾーンに登録 / 自動DNS機能と競合 | GoDaddy側でレコードが正しく有効になっていない |
ポイントは、DNSの問題か？ それともテナントの所有権の問題か？ を切り分けることです。
なぜ「DNSを直すだけ」では解決しないのか
DNSのTXT／MXレコードは、あくまで 「このドメインのDNSをコントロールできているのは誰か」 を証明する手段です。
- Entra ID がドメイン所有者を確認するために TXT／MX を探す
- 見つかれば「このテナントでこのドメインを使ってよい」とマークする
- 一度マークされたら、そのドメインは そのテナント専用 になる
つまり、旧テナント側ですでに「このドメインはうちのもの」と登録済みの場合、新テナントからいくらDNSを整えても「もう他で使われているからダメ」と弾かれる構造になっています。
Azure for Startups に参加すると、新しいテナント が払い出されますが、多くの企業はそれ以前に
- Microsoft 365 のトライアルを試していた
- 個人アカウントベースで M365 / Azure を契約していた
- ベンダーが勝手にテナントを立てていた
などの理由で、同じ会社ドメインが別のテナントで検証済み になっていることが珍しくありません。ここを整理しない限り、新テナントではいつまで経っても検証できない、というわけです。
おすすめ解決フローの全体像
最短ルートで解決するには、次の順番で進めるのが安全です。
- どのテナントにドメインが紐づいているかを特定する
- 旧テナント側からドメインを「完全に」削除する
- 現行テナントで TXT レコードを使って再検証する
- それでもNGなら、DNSの書き方／ゾーン／競合をチェックする
以下、各ステップを具体的に解説します。
ステップ1：どのテナントがドメインを掴んでいるか確認する
まずは「このドメインはいま、どのEntraテナントにひも付いているのか？」を確認します。
テナント検索サービスでテナントIDを調べる
代表的な方法は、ドメインからテナントIDを逆引きしてくれるWebサービスを使うことです。たとえば、よく知られている「whatismytenantid.com」のようなサイトでは、フォームに example.com のようなドメインを入力すると、
- テナント名（
contoso.onmicrosoft.com） - テナントID（GUID）
などを返してくれます。
ここで表示されたテナント名／テナントIDが、
- 自分が把握している既存テナントのもの → そのテナントで確認済みの可能性が高い
- 見覚えのないテナント名 → 誰かが過去に作った／自動作成されたテナント かもしれない
という判断材料になります。
| 検索結果のテナント | よくある実態 | 次のアクション |
|---|---|---|
| 社内で運用中のM365テナント | メール・Teams・SharePointなどで本番利用中 | そのテナントの管理者と相談し、ドメインをどちらで使うべきか決める |
| 昔の検証用テナント | 誰も使っていない／ライセンス切れ | サインインし、ユーザー等の参照外しをしてからドメイン削除 |
| 見覚えのないテナント | 「アンマネージド（シャドー）」テナントなど | ドメイン所有者として Admin Takeover やサポート問い合わせを検討 |
ここで「どのテナントが元凶なのか」を特定できるかどうかが、解決スピードを大きく左右します。
ステップ2：旧テナントでカスタムドメインを“完全に”解除する
犯人テナントが見えたら、そのテナント側からドメインをきれいに外します。
Entra 管理センターからドメインを削除する手順
旧テナントの全体管理者（グローバル管理者）またはドメイン管理者アカウントでサインインし、次のように操作します。
- Microsoft Entra 管理センターにサインイン
- 「ID > ドメイン名」 → 「カスタム ドメイン名」 を開く
- 問題のカスタム ドメイン（例：
example.com）を選択 - [削除] を実行
ここでよくハマるのが、「削除」ボタンがグレーアウトしている、またはエラーになるケースです。これは、そのドメインがまだ何かに使われている（参照されている）ことを意味します。公式には、以下のいずれかがドメインを使っていると削除できません。
- ユーザーの UPN（サインイン名）・メールアドレス
- グループ／配布リストのメールアドレス
- アプリケーションの「アプリID URI」
実務的には、次のような「参照外し」のチェックリストで潰していくとスムーズです。
| 対象 | 確認ポイント | 対応例 |
|---|---|---|
| ユーザー | UPN（@example.com になっているか？） | @tenant.onmicrosoft.com など既定ドメインに変更 |
| メールエイリアス | プロキシアドレスに @example.com が残っていないか | 不要なエイリアスを削除 |
| グループ / 共有メールボックス | メールアドレスに該当ドメインを使用していないか | 同様に既定ドメインへ変更 or 削除 |
| エンタープライズ アプリ | アプリID URIやリダイレクトURI等にドメインが含まれていないか | 必要に応じて別ドメインに変更 |
Microsoft 365 を併用している場合は、Microsoft 365 管理センターの「設定 > ドメイン」 からも、該当ドメインに割り当てられているサービス／アカウントを確認し、不要な割り当てを外しておくとトラブルを防げます。
旧テナントにアクセスできない場合：Admin Takeover / サポート依頼
「そのテナントの管理者が誰か分からない」「アカウントを失ってログインできない」といったケースでは、Admin Takeover（管理者による乗っ取り） または Microsoft サポートへの依頼 が必要になります。
- テナントが実態として組織で運用されておらず、誰も管理者権限を持っていないとみなされる場合、外部管理者がドメイン所有者としてそのテナントを引き継ぐ 手順が用意されています（External Admin Takeover）。
- その過程でも DNSにTXTレコードを追加する ことで、自分たちがドメインの持ち主であることを証明します。
詳細な手順は Microsoft Learn の「Admin takeover of an unmanaged directory」ドキュメントにまとまっているため、状況に応じて参照するとよいでしょう。
ステップ3：現行テナントで TXT レコードによる再検証を行う
旧テナントからドメインを削除できたら、あらためて 目的のテナント（Azure for Startups用など）でドメインを追加し直します。ここでは、TXT レコードでの検証を強く推奨します。
Entra ID側：TXTレコードの値を取得
- Microsoft Entra 管理センターに、新しいテナントの管理者でサインイン
- 「ID > ドメイン名 > カスタム ドメイン名」 を開き、[+ カスタム ドメインの追加] をクリック
- 自社ドメイン（例：
example.com）を入力して追加 - 表示される検証手順の中から 「TXTレコード」 の値を控える
- 形式例：
MS=ms12345678
- 形式例：
Microsoft公式の手順でも、TXTレコードの追加が標準的な方法として案内されています。
GoDaddy側：TXTレコードを追加する
次に、GoDaddy のDNS管理画面で TXTレコードを追加します。TXTレコードは、本来まさに ドメイン所有者の検証 のために使われるレコード種別であり、Microsoft 365 や各種SaaSサービスでも一般的な方式になっています。
代表的な設定内容は次のようになります。
| 項目 | 設定例（Entra IDのTXT検証） |
|---|---|
| タイプ | TXT |
| ホスト名（Name） | @（空欄でも @ と同義と扱うUIもあります） |
| 値（TXT Value） | MS=ms12345678（Entraポータルに表示された文字列をそのままコピペ） |
| TTL | 1時間 または 既定値（3600秒など） |
GoDaddyのヘルプでも、TXTレコードは「ドメイン所有権の検証やSSL検証などに使う」と説明されており、Microsoft 365 のセットアップ手順でも同様に TXT 追加 → ポータル側で [確認] という流れになっています。
MXレコードでも検証自体は可能ですが、
- 優先度の設定を誤るとメールルーティングに影響が出る
- GoDaddy側の自動MX設定（Microsoft 365 メール機能など）と競合しやすい
といったリスクがあるため、検証専用で完結するTXTレコード方式が安全です。
ステップ4：DNS伝播と検証状態をセルフチェックする
TXTレコードを追加したら、Entra ID の「確認」ボタンを押す前に、必ず 自分でDNSを確認 しておきましょう。
基本チェック：nslookup / dig でTXTを確認
まずは一般的なDNS解決経路でTXTが見えているかを確認します。
nslookup -type=TXT example.com
Linux / macOSなどであれば、次のように digでもOKです。
dig TXT example.com
ここで、応答の中に "MS=ms12345678" のような文字列が含まれていれば、グローバルDNS的にはレコードが見えている と判断できます。
さらに確実に：GoDaddyの権威DNSサーバーを直接たたく
DNSのキャッシュの影響を減らしたい場合は、GoDaddyが公開している権威ネームサーバーを直接指定してTXTを引くのがおすすめです。
nslookup -type=TXT example.com nsXX.domaincontrol.com
nsXX.domaincontrol.com の部分は、実際にそのドメインに割り当てられているネームサーバー名に置き換えてください。
この状態で MS=ms12345678 が返ってくるなら、少なくともDNS設定は問題なく、残る原因は「Entra側のテナント／キャッシュ」 に絞り込めます。
公式のQ&Aでも、DNSの変更が完全に行き渡るまでに最大72時間程度かかる可能性があると案内されていますが、現実的には数分〜数時間で反映されることが大半です。
Entra ID側で再検証
DNS側で正しくTXTが返ってくることを確認できたら、Entra管理センターに戻り、
- 対象ドメインの詳細画面を開く
- [確認] ボタンをクリックする
ここでようやくステータスが 「確認済み」 に変われば成功です。
まだ検証できないときの「よくある落とし穴」と対処法
ここまでやってもダメな場合は、次のようなパターンを一つずつ潰していくと解決につながります。
TXTとMXをあれこれ追加しすぎて混乱している
- 「念のため」TXTもMXも複数作り、どれが有効か分からなくなっている
- 古い検証用のTXTが残ったまま、新しいTXTを追加している
検証用レコードは基本的に 1つの値だけ で十分です。古い検証値は削除し、Entraが指示した最新のTXTのみを残しましょう。
TXT値に全角文字や余分な引用符が混ざっている
- コピー＆ペースト時にダブルクォーテーション（
"）まで含めてしまう - エディタの都合で全角スペースや全角イコールが紛れ込む
GoDaddyのUIでは通常、自動的にTXT値をダブルクォーテーションで囲んでくれます。そのため、手入力側では MS=ms12345678 だけ をコピペし、「"」は含めない方が安全です。
ホスト名を www にしてしまっている
Entra ID のドメイン検証用TXTは、ルートドメイン（@） に対して設定する必要があります。
www.example.comにTXTを入れても、Entraが参照するのはexample.com- GoDaddy の「ホスト名」に
wwwと入力してしまうと、別の場所にレコードが作られる
検証用レコードは、必ず ホスト名を @ または空欄（UI仕様による）にして登録してください。
別ゾーン（サブドメイン側）に追加している
DNSホスティングを細かく分けている場合、
- ルートドメイン：GoDaddy
- サブドメイン：別のDNSサービス（CloudflareやRoute 53など）
といった構成になっていることがあります。このとき、sub.example.com 側のゾーンにTXTを追加しても、Entra ID が見るのは example.com のゾーンです。
公式ドキュメントでも、先にルートドメインを追加・確認しておく必要がある こと、別テナントでサブドメインを使う場合の挙動などが解説されています。
GoDaddyの「自動DNS設定」機能と競合している
GoDaddyで Microsoft 365 メールサービスを契約している場合、「メールのセットアップ」ウィザードが自動的に DNS レコード（MXやTXT）を追加・変更することがあります。
- GoDaddy側の自動設定が TXT/MX を上書き
- Entra IDが期待する値と異なるレコードが残る
といった状態になると、検証がうまくいきません。一度、
- 自動生成されたDNSレコードを洗い出す
- Entra検証用のTXTと競合していないか確認する
といったメンテナンスをすることをおすすめします。
旧テナント側での参照がまだ残っている
ユーザーやグループ、アプリなどにドメインが少しでも残っていると、ドメイン削除は成功したように見えて実はエラー になっているケースもあります。削除時のエラーメッセージをよく読み、該当リソースをすべて修正したうえで再度削除を試みましょう。
Azure for Startups で特に起こりやすいシナリオ
Azure for Startups で新しいテナントをもらったケースでは、次のようなストーリーが非常によく見られます。
- 数年前に、情報システム担当が 別テナント で Microsoft 365 を試していた
- そのとき、自社ドメイン（
example.com）を Azure AD（現Entra ID）に追加・検証している - その後、そのテナントは放置され、管理者も誰だか分からなくなった
- 今回 Azure for Startups で 新テナント を作り、同じドメインを追加しようとしている
結果として、
- DNS的には正しくTXT/MXが設定されている
- しかし Entra ID 側から見ると「そのドメインは昔のテナントで既に使われている」
という状態になり、エラーが出続けることになります。
この場合の最短解は、
- テナント検索で「昔のテナント」を特定する
- 可能であれば、そのテナントにログインできるアカウントを捜索する
- 請求書、契約書、過去のメールを探す
- 当時の担当者に心当たりがないか確認する
- ログインできたら、本記事で説明した手順で
- ユーザーUPN・メールアドレス等からドメインを外す
- カスタムドメインを削除する
- どうしても管理者が分からない場合は、DNS所有者として Admin Takeover や Microsoft サポートに相談する
- そこまで完了したうえで、Azure for Startups テナント側で TXT 検証をやり直す
という流れになります。
運用とセキュリティの観点からのベストプラクティス
一度はまるとかなり時間を奪われるトラブルなので、今後同じことを繰り返さないための運用ルール作りも重要です。
どのテナントでどのドメインを使っているか「台帳化」する
- Entraテナント名
- テナントID（GUID）
- 「確認済み」のカスタムドメイン一覧
- 用途（本番 / 検証 / PoC / ベンダー管理など）
これらをスプレッドシートなどで一元管理しておくと、「あのドメインはどこで使っていたっけ？」問題をかなり減らせます。
本番ドメインは1テナントに固定し、他テナントはサブドメインで運用する
Microsoftのドキュメントでも、1つのテナントには最大5000個のカスタムドメインを追加できる、といった制限が示されていますが、ドメインの所有はテナント単位で排他的であるという点が根本にあります。
example.com：本番M365／メインEntraテナントでのみ使用dev.example.com/test.example.com：開発用テナントで使用（必要に応じてサブドメインを別テナントに追加）
といった構成にすると、ドメイン取り合いのリスクを減らしつつ、環境ごとの切り分けもしやすくなります。
GoDaddyの自動DNS機能は「何をしているか」を理解してから使う
GoDaddyはMicrosoft 365 などと連携した「自動DNS設定」機能を提供しており、ボタン一つで必要なレコードを追加してくれる反面、Entra検証用のTXT/MXと競合する可能性があります。
- 自動ウィザードを多用する場合は、「このボタンを押すとどんなレコードが追加／変更されるか」を事前に確認する
- 検証で一時的に使ったTXTレコードは、ドメインが「確認済み」になった後に整理する（削除してもOKな場合が多い）
といった使い方を心がけると、後々のトラブルをかなり減らせます。
最短で解決するためのチェックリスト
最後に、本記事の内容をもとにした「最短解決チェックリスト」をまとめます。実際の作業時に、メモ代わりに使ってください。
- □ テナント特定：テナント検索サービス等で、ドメインが紐づいているテナントIDを特定した
- □ 旧テナントの整理：
- ユーザーUPN／メールアドレスから当該ドメインを外した
- グループ・共有メールボックス・エイリアスからドメインを外した
- アプリのアプリID URI・リダイレクトURIなどでドメイン参照がないか確認した
- Microsoft 365 管理センター側でもドメイン割り当てを確認・整理した
- そのうえで、旧テナントからカスタムドメインの削除に成功した
- □ 現行テナントのDNS検証：
- Entra 管理センターでドメインを追加し、最新の
MS=ms########を控えた - GoDaddyのDNSに、ホスト名
@のTXTレコードとして正しく登録した nslookup -type=TXT example.comやnslookup -type=TXT example.com nsXX.domaincontrol.comでTXTが見えることを確認した- Entra 管理センターで [確認] を押し、ステータスが 「確認済み」 になった
- Entra 管理センターでドメインを追加し、最新の
- □ うまくいかない場合の再確認：
- TXT/MXレコードが複数・重複していないか
- 値に全角文字や余分な引用符が紛れ込んでいないか
- ホスト名が
wwwなどになっていないか - 誤ってサブドメイン側のゾーンに追加していないか
- GoDaddyの自動DNS機能による競合がないか
この流れで進めれば、「GoDaddyに何度レコードを追加してもEntra IDのドメイン検証が通らない」という状況は、ほとんどのケースで解消できます。特に、旧テナントで既に確認済みだったドメインを、新テナントで使い直す ケースでは、ここで紹介した手順で実際に復旧した事例が多数あります。
同じ問題に悩んでいる方の時間と労力の節約につながれば幸いです。
コメント