GoDaddyで購入した独自ドメインをMicrosoft Entra ID（旧Azure AD）へ追加し、TXTレコードも参照できるのに「Unable to verify domain name…」で検証（Verify）が失敗し続ける――この症状は、DNSの伝播遅延や入力ミスではなく「そのドメインが既に別のEntraテナントで検証済み」というケースが原因のことがあります。切り分けと解決手順を実務目線でまとめます。
症状：TXTレコードは見えるのに、Entra IDのVerifyだけが失敗する
Microsoft Entra IDでカスタムドメインを追加した後、画面の指示どおりにGoDaddy側へTXTレコードを設定し、数時間〜数日待っても、検証ボタン（Verify）を押すと次のようなエラーが繰り返し表示されることがあります。
- Unable to verify domain name（DNSレコードを追加して再試行して、という趣旨）
- 「TXTは追加した」「dig / nslookupでもTXTは返ってくる」「72時間以上待った」
- ドメインを削除→再追加、TXTの作り直し、TTL調整も効果なし
この時点で「DNSが見えている＝検証に通るはず」と考えがちですが、Entra IDのドメイン検証にはDNS以外の“制約”が存在します。
結論：DNSではなく「別テナントで既に検証済み」が原因だった
結論から言うと、最終原因が「その独自ドメインが既に別のMicrosoft Entraテナントで検証済みとして残っている」ケースがあります。これが起きていると、TXTレコードが正しく参照できても、こちらのテナントではVerifyが通りません。
| ポイント | 内容 | 実務上の影響 |
|---|---|---|
| 同時に1つのテナントでしか検証できない | カスタムドメインは「検証済み」状態を複数テナントに持てません。 | 新しいテナント側でTXTが合っていてもVerifyが失敗し続けます。 |
| DNS伝播や入力ミスではないことがある | dig/nslookupでTXTが引ける、権威DNSでも一致、待機時間も十分。 | DNSの調整を続けても改善しない“沼”に入りやすいです。 |
| 解決は「元のテナントでドメインを削除」 | 既に検証済みのテナントからドメインを削除できれば、こちらで検証できる可能性が高いです。 | 旧テナントにアクセスできない場合は、関係者への依頼やMicrosoftサポートが現実的になります。 |
なぜ起きる？GoDaddyで“最近買ったドメイン”でも発生する理由
「新品で買ったのに、なぜ別テナントで検証済み？」と疑問が出ますが、実務では以下のような背景で起きます。
| 背景 | 起きやすいシナリオ | ありがちな誤解 |
|---|---|---|
| ドメインが過去に運用されていた | 期限切れ→再取得（中古ドメインのような状態）。以前の所有者がMicrosoft 365/Entraで使っていた。 | 「新規購入＝誰も使っていない」は必ずしも成立しません。 |
| 移管や売買の過程で“削除し忘れ” | 売却・事業譲渡・運用委託（MSP）などで、旧テナントからのドメイン削除が完了していない。 | 「DNSを変えれば切り替わる」だけでは解決しません。 |
| 旧テナントに残骸が残っている | ユーザーUPN/メールアドレス/アプリ設定に紐づいたままで削除できず、結果として居座る。 | 「テナントから消したつもり」でも、紐づきが残ると削除できません。 |
つまり、DNSの正しさだけでは説明できない“所有権の二重管理”が発生している可能性がある、ということです。
まずやるべき切り分け：DNS側が本当に正しいかを短時間で確認する
「別テナントで検証済み」が本命であっても、DNSが正しくないと議論が進みません。まずは“権威DNSに正しく入っているか”を確認して、DNS起因の可能性を手早く潰します。
チェック観点：キャッシュではなく、権威DNSに入っているか
手元のPCや一部リゾルバでTXTが見えても、キャッシュで見えているだけのことがあります。次の観点を押さえます。
| 観点 | 確認方法 | OKの目安 | NGの典型 |
|---|---|---|---|
| ネームサーバーがどこか | ドメインのNSを確認（WHOISやdig NSなど） | 「今DNSを編集している場所」とNSが一致 | GoDaddyで編集しているのにNSが別サービス（例：Cloudflare） |
| 権威DNSへの直接問い合わせ | 権威NSを指定してTXTを引く | Entraが指定したTXT値が一致 | 権威側に入っていない／別の値が返る |
| ホスト名（@）が正しいか | GoDaddyのTXTの「Host」が@か、空欄相当か確認 | ルート（example.com）にTXTが存在 | 「entra.example.com」等に誤って入れている |
| 値の欠け・余計な空白 | コピー後に前後の空白、ダブルクォートの有無を見直す | 指示された値が完全一致 | 末尾に空白、途中改行、見た目は同じでも文字列が違う |
コマンド例：TXTが“どこで”見えているかを確認する
以下は代表的な確認方法です。ドメイン名は自分のものに置き換えてください。
一般的な確認（ローカルの設定や経路に依存）
nslookup -q=TXT example.com
dig TXT example.com +short特定の公開DNSで確認（結果がばらつく場合の比較）
dig @8.8.8.8 TXT example.com +short
dig @1.1.1.1 TXT example.com +short権威DNSへ直接確認（最重要）
GoDaddyのネームサーバーを使っているなら、ドメインのNS（例：nsXX.domaincontrol.com）を指定してTXTを引きます。
dig @nsXX.domaincontrol.com TXT example.com +shortここまでで「権威DNSに正しいTXTが入っている」「複数リゾルバでも同じ値が返る」状態が確認できたら、DNS起因の可能性はかなり下がります。
DNSが正しいのにVerifyできない時に最優先で疑うべきこと
次の条件が揃っているのにVerifyが通らない場合、“別テナントにドメインが居座っている”可能性が高いです。
- 権威DNSにTXTが存在し、値も完全一致している
- 72時間以上待っても状況が変わらない（待機で改善しない）
- ドメイン削除→再追加、TXT作り直しでも改善しない
- MXやAではなく、Entra指定のTXTのみを検証しているのに失敗
このパターンは、DNSの問題としてトラブルシュートを続けるほど時間を溶かしやすいので、早めに方針転換するのが重要です。
原因の本質：カスタムドメインの「検証済み」はテナントにひも付く
Microsoft Entra IDのカスタムドメインは、単にDNSにTXTがあるかだけを見ているわけではありません。運用上、次の制約があります。
- カスタムドメインは“検証済み（Verified）”の状態を同時に複数テナントに持てない
- そのため、過去のテナントに検証済みとして残っていると、別テナントでの検証に進めない
ここが理解できると、digでTXTが見えていても失敗し続ける理由が腑に落ちます。つまり、DNSが正しくても、Microsoft側のディレクトリ管理上の制約でブロックされている、という状態です。
解決策：元のテナントからドメインを削除してもらう
最も確実な解決策はシンプルで、「既に検証済みのテナント側で、そのドメインを削除」してもらうことです。削除が完了すれば、こちらのテナントでVerifyできるようになることが多いです。
「削除してもらう」の具体的な依頼内容
旧所有者や関係者（委託先、MSP、前任の管理者など）に依頼できるなら、次のように伝えると話が早いです。
- 「Microsoft Entra ID（Azure AD）またはMicrosoft 365テナントに、example.com が登録・検証済みで残っている可能性がある」
- 「そのテナントから example.com を削除してほしい（削除できない場合は、どこに紐づいているか確認して解除してほしい）」
- 「削除後、こちらでTXT検証をやり直す」
旧テナント側で削除できない場合によくある“詰まりどころ”
ドメイン削除は、テナント内でそのドメインが使われているとブロックされます。典型例を表にまとめます。
| 削除できない主因 | 何が残っている？ | 対処の方向性（旧テナント側） |
|---|---|---|
| ユーザーのサインイン名（UPN） | [email protected] のようなUPNが残っている | 一時的に [email protected] へ変更してから削除を試す |
| メール関連（Microsoft 365） | Exchange Onlineの受信ドメイン、プロキシアドレス、メールボックスの主アドレス | アドレスや受信設定の切り替え、ドメイン解除の手順を踏んでから削除 |
| グループやアプリの参照 | グループのメール、アプリの識別子、通知先など | 当該ドメインの参照箇所を検索して置換・削除 |
| 同期・ハイブリッド構成 | Entra Connectで同期される属性やオンプレAD側のUPN | 同期元の属性も含めて変更し、同期後に再度削除 |
旧テナント側で「削除ができない」と言われた場合は、単に操作権限がないのではなく、何かが紐づいていて削除条件を満たしていないケースがよくあります。上の表をもとに、どこに依存があるかを特定してもらうのが近道です。
元のテナントが不明・連絡先がない場合の現実的な選択肢
困るのが「前の所有者が誰かわからない」「管理していたテナントが不明」「連絡手段がない」ケースです。この場合、こちら側だけで完結できることは限られます。
| 選択肢 | 何をする？ | メリット | 注意点 |
|---|---|---|---|
| 以前の所有者・関係者へ依頼 | 売買・移管経路をたどって、旧テナント管理者を探して削除依頼 | 通れば最短で解決 | 相手が不明だと時間がかかる |
| Microsoftサポートへ相談 | ドメイン所有権を示し、テナント移行（解放）について相談 | 第三者テナントが絡む場合の公式ルート | 契約形態や状況により対応範囲が変わる可能性 |
| 代替ドメインを使う | 別ドメイン・別サブドメイン（例：id.example.com）で運用を進める | 待ち時間を最小化できる | ブランド/メール/ログイン名など設計の見直しが必要 |
| 一旦自テナントから削除して整理 | 自テナントに追加しただけの状態なら一度削除し、状況整理 | 混乱を減らせる | 根本原因が消えるわけではない |
Microsoftサポートに相談するなら用意しておきたい情報
サポートに話が通りやすくなるよう、最低限次の情報を準備しておくのがおすすめです。
- 対象ドメイン名（example.com）
- 現在の管理者であることを示す資料（GoDaddyの管理画面のスクリーンショット、購入証跡、請求書など）
- Entra管理センターでのエラー内容（スクリーンショット）
- 実際に設定しているTXTレコードの値
- dig/nslookup結果（権威DNSで一致していることが分かるもの）
ポイントは「DNSは正しいのにVerifyできない」ことを説明するだけでなく、“他テナントで検証済みの可能性”を明確に伝えることです。話がDNS伝播の一般論に戻されにくくなります。
実務で役立つ：同種トラブルの“切り分け”を短縮するチェック表
「TXTは見えるのにVerifyが通らない」問題は、原因が複数あります。闇雲に試行錯誤すると時間が溶けるため、チェック表で短縮します。
| チェック項目 | YESなら次へ | NOなら対処 | 補足 |
|---|---|---|---|
| Entraが提示したTXT値を完全一致で入れたか | ネームサーバー確認へ | コピペし直し（前後の空白・改行・欠けを排除） | 見た目が同じでも、空白混入で失敗することがあります |
| DNSを編集している場所とNS（権威DNS）が一致しているか | 権威DNSのTXT確認へ | DNS管理元を揃える（GoDaddy/Cloudflare等） | GoDaddyで編集してもNSが別なら反映されません |
| 権威DNSを指定してもTXTが返るか | テナント占有を疑う | 権威DNSに正しく入れ直す | ここでOKなら「伝播待ち」の可能性は下がります |
| 72時間以上待っても改善しないか | 旧テナント削除/サポートへ | TTLやキャッシュの可能性を再確認 | 長期化は“別テナント”の典型サインです |
手順：こちら（新テナント）側でできる最短の進め方
旧テナント側の対応が必要になりがちな問題だからこそ、新テナント側は“ムダ撃ち”を減らして進めるのが重要です。おすすめの手順です。
- Entraが提示するTXT値を控える（コピー先のメモを作り、編集履歴が残るようにする）
- ネームサーバー確認（DNSを編集しているサービスと一致するかを最初に潰す）
- 権威DNSへ直接問い合わせしてTXTが返ることを証明する（スクリーンショットや出力保存）
- 72時間待ってもVerifyできない場合は、「別テナントで検証済み」仮説に切り替える
- 旧テナント関係者にドメイン削除依頼（削除できない場合は紐づき解除の調査依頼）
- 連絡先がない場合は、Microsoftサポートor代替ドメインで並行対応
この流れにしておくと、「DNSの確認」「証拠の確保」「次のアクション」が一直線になり、社内説明やサポート依頼も通しやすくなります。
回避策：ドメイン購入・移管時に“検証済み居座り”を避けるコツ
同じトラブルを繰り返さないために、ドメイン取得や移管のタイミングで意識しておくと効果が高いポイントをまとめます。
| タイミング | やること | 狙い |
|---|---|---|
| ドメイン売買・譲渡の前 | 旧所有者に「Microsoft 365/Entraテナントからのドメイン削除」を契約条件として明文化 | 後から追えない“連絡不能”を防ぐ |
| 移管直後 | DNSを触る前に、NSがどこを向いているか確認して記録 | 「編集しているのに反映されない」事故を防止 |
| 本番切替前 | 本番用ドメインが詰まった場合に備え、サブドメイン運用案を用意（例：login.example.com） | 業務停止を避け、並行で解放手続きを進められる |
特にドメインの売買や事業譲渡が絡む場合、技術面だけでなく“手続き”の設計が効きます。DNSは自分で直せても、他テナントに残った検証済み状態は自力で剥がせないことがあるためです。
よくある質問
TXTが引けるのにVerifyが失敗するのは、Microsoft側が古いDNSを見ているから？
可能性としてゼロではありませんが、権威DNSに正しいTXTが入り、複数の公開DNSでも同じ値が返っているのに長期間改善しない場合は、DNS伝播よりも別テナントで検証済みの方が疑わしいです。まずは権威DNS指定の結果を根拠に、原因仮説を切り替えるのがおすすめです。
ルート（@）にTXTが複数あると失敗しますか？
一般に、ルートのTXTが複数存在しても直ちに失敗とは限りません。ただし、値が欠けたり、余計な空白や改行が混入したりすると一致判定に失敗します。特に管理画面での自動整形が入る場合があるため、設定後はdigで実値を確認してください。
旧テナントが削除できたかどうかはどうやって分かりますか？
旧テナントでドメインが削除できた場合、こちらのテナントで再度Verifyを実行すると通ることが多いです。削除直後に反映まで少し時間がかかる場合もあるため、DNSをいじらず、一定時間を置いてから検証を試すのが安全です。
どうしても急ぎでユーザーを作りたい場合は？
ドメインが解放されるまで待てない場合は、いったんテナント既定の onmicrosoft.com ドメインでユーザーを作成し、後からUPNを切り替える運用が現実的です。メール運用やサインイン名の設計に影響するため、移行手順と周知計画は合わせて用意しておくとスムーズです。
まとめ：Verify失敗が長期化したら“別テナント居座り”を疑う
Microsoft Entra IDのカスタムドメイン検証で「TXTは見えるのにVerifyできない」場合、DNSを疑うのは自然です。しかし、権威DNSまで確認して問題がないなら、原因がDNSではない可能性が高まります。
- TXTが正しいのに失敗し続けるときは、「別テナントで既に検証済み」が決定打になることがある
- 解決の中心は、旧テナントからのドメイン削除（紐づき解除を含む）
- 旧テナントが不明なら、関係者探索・Microsoftサポート・代替ドメインを現実的に検討する
DNSで消耗しやすいトラブルだからこそ、最初に「権威DNSでの証明」と「別テナント仮説への切り替え」をセットで行うと、最短距離で解決に近づけます。
コメント