Azure Entra ID（旧Azure AD）で独自ドメイン syntralyn.nz を追加し、DNS に TXT レコードも設定したのに「ドメイン名を確認できません」と出て検証が進まない…。旧テナントで利用していた／削除した等の条件が重なると、DNS が正しくても詰まることがあります。原因の切り分けから最短の解決ルートまで、手順を具体的に整理します。
症状：TXT レコードを入れたのに Entra ID で「検証できない」
Azure ポータル（または Microsoft Entra 管理センター）で syntralyn.nz を「カスタム ドメイン名」として追加し、案内どおりに DNS に TXT レコード（MS=msXXXXXXXX のような値）を登録したにもかかわらず、Entra ID 側で次のようなエラーが続くケースがあります。
- 「ドメイン名を確認できません。…」
- 「レコードを追加したことを検出できません」
- （別画面では）「別のディレクトリで既に使用されています」
見た目は「DNS が間違っている」ように見えますが、実際にはDNS が正しいのに検証できないパターンが存在します。ポイントは、切り分けを「DNS」と「テナント紐づけ」の2系統で考えることです。
まず押さえる：Microsoft 365 と Entra ID のドメイン確認は似ていて、違う
Microsoft 365 管理センター（Exchange Online / Microsoft 365 側）でも、Entra ID でも、ドメイン所有の確認は TXT（または MX）レコードで行うのが基本です。ところが、Entra ID 側の検証は「DNS が見えるか」だけではなく、そのドメインが他のテナントで既に検証されていないかもチェックします。ドメインは同時に1つのディレクトリでしか検証できないため、別テナントに残っていると新テナントでは先へ進めません。
| 観点 | Microsoft 365 管理センター | Entra ID（Azure AD） |
|---|---|---|
| 所有確認の方法 | TXT / MX レコードで確認 | TXT / MX レコードで確認 |
| 詰まりやすいポイント | DNS 伝播、参照（ユーザー/グループ/メール） | DNS 伝播 + 「別テナントで検証済み」判定 |
| 旧テナントの影響 | 状態反映のタイムラグが出ることがある | 旧テナントに紐づいていると検証自体が止まりやすい |
結論：原因は大きく「DNS 側」か「別テナントに紐づいている」か
Microsoft Learn の公式ドキュメントでも、カスタム ドメインの検証が失敗する代表例として、次のような観点が挙げられています。
- DNS 伝播が終わっていない（待つ必要がある）
- DNS レコードが正しくない（値・場所・重複など）
- ドメインが別のディレクトリ（テナント）で既に検証済みで、重複して検証できない
- 未管理（unmanaged）ディレクトリが存在していて、ドメインがそちらにぶら下がっている
特に「別テナントで検証済み」の場合は、TXT が合っていても新しいテナントでは検証できません。これは仕様です。
最短で切り分けるチェック表
| チェック項目 | すぐ分かるサイン | 次にやること |
|---|---|---|
| 同じテナントを見ているか | Microsoft 365 管理センターでは「確認済み」なのに、Entra 側は未確認 | テナント ID を突き合わせる（ディレクトリ切替ミスを潰す） |
| TXT が外部から引けるか | nslookup/dig で値が出ない・違う | ホスト名（@/空欄）・値・TTL・重複 TXT を再確認 |
| 別テナントに紐づいていないか | OpenID 設定 URL が「知らないテナント ID」を返す | 旧テナントでドメイン削除／アクセス不可ならサポートへ解放依頼 |
| 旧テナント削除後の解放待ちか | 旧テナントを削除した直後から再利用できない | 解放処理の完了を待つ／急ぐなら Data Protection チーム経由で解放 |
ステップ：まず「同じテナント」を見ているか確認する
「Microsoft 365 管理センターでは syntralyn.nz が確認済み」と表示されるのに、Entra ID 側で検証できない場合、最初に疑うべきはテナントの取り違えです。
Azure ポータルや Entra 管理センターは、アカウントが複数テナントに所属していると、画面右上のディレクトリ切替で別テナントに入ったまま操作してしまうことがあります。Microsoft 365 管理センターと Entra 管理センターで、次の情報を必ず突き合わせてください。
- テナント ID（GUID）
- 初期ドメイン（
xxxxx.onmicrosoft.com） - 組織名（表示名）
テナントが一致していれば、本来「ドメインの確認」という状態は双方で整合しやすい設計です。逆に、テナントが違えば、片方で確認済みでももう片方では永遠に確認できません（別テナント扱い）。
目視で迷うときのコツ
- Entra 管理センター：概要ページに表示される「テナント ID」を控える
- Microsoft 365 管理センター：組織情報（Organization profile）などに表示される「テナント ID」を控える
- 控えた 2 つの GUID が一致しているか比較する
ここが一致していない場合、まず「正しいテナントに入り直す」が最短ルートです（DNS をいじっても解決しません）。
ステップ：DNS TXT レコードを「外部のDNSサーバー」から確認する
Entra の検証は、あなたのPCの DNS キャッシュではなく、インターネット上の DNS 参照結果で行われます。ローカルで見えているつもりでも、外部から見えていないことがよくあります。Microsoft Learn でも、伝播は即時の場合もあれば数日かかる場合もある、とされています。
確認コマンド（Windows / macOS / Linux）
まずは「指定のリゾルバ」を使って確認すると、キャッシュの影響を受けにくくなります。
nslookup -type=TXT syntralyn.nz
nslookup -type=TXT syntralyn.nz 1.1.1.1
nslookup -type=TXT syntralyn.nz 8.8.8.8dig TXT syntralyn.nz +short
dig @1.1.1.1 TXT syntralyn.nz +short
dig @8.8.8.8 TXT syntralyn.nz +short出力に Entra が要求する MS=msXXXXXXXX が含まれているか確認してください。値が一致していても、古い MS= が複数残っていると、環境によっては検証の判定が安定しないことがあります。不要な TXT は整理し、検証用 TXT を必要最小限にするのが安全です。
DNS 設定でハマりやすいポイント
| よくあるミス | 症状 | 対処 |
|---|---|---|
ホスト名に syntralyn.nz を入れて二重になる | syntralyn.nz.syntralyn.nz のような場所に TXT が作られる | DNS 管理画面の「ホスト」は @ / 空欄 / syntralyn など、レジストラ仕様に合わせる |
| TXT の値に余計な空白・引用符が入る | nslookup では見えるが値が微妙に違う | Entra が表示する値をそのままコピペ（前後の空白も除去） |
| TTL が極端に長い | 修正しても反映が遅い | 可能なら TTL を 3600 秒（60分）程度にして待つ |
| 同一ホストの TXT が多すぎる | 検証が通ったり落ちたりする | 検証用 TXT を必要最小限にする（古い MS= を削除） |
公式手順では TXT/MX レコードの TTL を 3600 秒（60分）に設定する例が示され、誤った情報を入れた場合は TTL が切れるまで再試行できないことがある点も注意事項として明記されています。
ステップ：ドメインが「別テナントに紐づいている」か判定する
DNS が正しく見えているのに検証できない場合、次に疑うのは「そのドメインが別テナントで既に検証されている」パターンです。Microsoft Learn でも「ドメインは1つのディレクトリでしか検証できない」ことが明確に記載されています。
OpenID 設定エンドポイントで“紐づき”を確認する
ドメインが Entra のサインイン基盤に紐づいている場合、次の URL で OpenID の設定が返り、そこにテナント ID が含まれることがあります。
https://login.microsoftonline.com/syntralyn.nz/v2.0/.well-known/openid-configuration返ってくる JSON の issuer や authorization_endpoint に、https://login.microsoftonline.com/<テナントID>/v2.0 のような形で GUID が含まれていれば、「そのドメインがどこかのテナントにぶら下がっている」可能性が高いです。
ここで出てくるテナント ID が、あなたが今操作しているテナント ID と一致しない場合は、DNS だけ頑張っても前に進みません。旧テナント側でドメインを削除するか、旧テナントにアクセスできないならサポートに解放を依頼するルートになります。
旧テナントにアクセスできる場合：ドメインを「正攻法で削除」して解放する
旧テナントへサインインできるなら、最も確実なのは旧テナント側で syntralyn.nz を削除して解放することです。ドメイン削除は、ユーザー・グループ・アプリがそのドメインを参照しているとブロックされます。
削除がブロックされる代表的な“参照”
- ユーザーのサインイン名（UPN）やメール属性（ProxyAddress など）
- グループのメールアドレスや ProxyAddress
- アプリ登録の App ID URI / Identifier URI
公式ドキュメントでも、これらが残っているとドメインを削除できないことが明記されています。
実務での削除手順（全体像）
- 旧テナントで既定ドメインを
onmicrosoft.comに戻す（必要なら「主ドメイン」に設定） - ユーザーの UPN・メール属性から
@syntralyn.nzを外す - グループ／配布リスト／共有メールボックス等のメール関連属性から外す（Exchange 管理センター側が必要な場合あり）
- アプリの Identifier URI に
syntralyn.nzが入っていないか確認し、別の URI に変更する - Entra ID の「カスタム ドメイン名」からドメインを削除する
Microsoft 365 側のガイドでも、ユーザー・グループを別ドメインへ移し、最後にドメインを削除する流れが案内されています。参照が多いと削除に数時間〜1日程度かかる場合がある点も、あらかじめ織り込んでおくと運用が安定します。
削除できないときの切り札：ForceDelete（条件付き）
「参照が多すぎて手作業がつらい」「でも旧テナントはもう使わない」という場面では、Entra 側に ForceDelete（強制削除）オプションがあります。これは非同期で参照を書き換えながら削除する仕組みで、完了まで最大 24 時間かかることがある、とされています。
ただし ForceDelete には条件があります。例えば、参照（置換対象）が 1,000 未満であること、Exchange がプロビジョニングする一部オブジェクト（メール有効なセキュリティグループや配布リスト等）が残っていないこと等が挙げられています。影響として、対象ユーザーが無効化される可能性もあるため、旧テナントの整理目的でのみ慎重に使うのが現実的です。
PowerShell（Microsoft Graph）で「検証値の取得」と「確認」を行う
ポータルの表示が分かりにくいときは、Microsoft Graph PowerShell で「今のテナントにどのドメインが存在するか」「検証用 TXT の値は何か」を確認できます。公式ドキュメントでも Get-MgDomain、Get-MgDomainVerificationDnsRecord、Confirm-MgDomain の流れが例示されています。
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
# いま接続しているテナントのドメイン一覧
Get-MgDomain | Select-Object Id, IsVerified, IsDefault
# syntralyn.nz の検証用 DNS レコード（TXT）を取得
(Get-MgDomainVerificationDnsRecord -DomainId "syntralyn.nz" | Where-Object {$_.RecordType -eq "Txt"}).AdditionalProperties
# TXT を DNS に入れた後、確認（Verify 相当）
Confirm-MgDomain -DomainId "syntralyn.nz"ポイントは「正しいテナントに接続しているか」です。まず Get-MgDomain で xxxxx.onmicrosoft.com が想定どおりか確認してから操作すると、テナント取り違え事故を防げます。
旧テナントを削除してしまった／アクセスできない場合：サポートで「ドメイン解放」
質問概要のように「旧テナントとサブスクリプションは削除済みで、削除前にカスタムドメインを外していないかもしれない」ケースでは、ドメインがバックエンドで旧テナントに紐づいたまま残り、新テナント側で検証できないことがあります。
Microsoft Q&A でも、テナントを削除した後にドメインがすぐ解放されず、OpenID 設定の解決先が旧ディレクトリのまま残ってしまう事例が報告されています。この場合、ポータル上の操作だけで解決できず、サポート経由でドメインの関連付けを外してもらう必要がある、という流れになります。
サポートに依頼するときに用意しておく情報
| 用意するもの | 理由 |
|---|---|
| 対象ドメイン（例：syntralyn.nz） | どのドメインを解放するかを明確にするため |
| 現在利用したいテナント ID（新テナント） | 解放後にどこへ紐づけたいかの確認に使われる |
| OpenID 設定 URL の結果（旧テナント ID が出る場合） | バックエンド紐づきの調査材料になる |
| DNS で TXT を設定できる証拠（スクリーンショット等） | ドメイン所有の確認（サポート側が要求することがある） |
| 連絡先（メール、電話、国、タイムゾーン） | Data Protection チームが追加確認を行うため |
Microsoft Q&A の回答例でも、Data Protection チームに連携するためにテナント ID や連絡先情報を提示してサポート チケットを進める流れが示されています。
Microsoft 365 側のサポート導線も活用する
Microsoft 365 管理センターには、ヘルプからサポートに連絡する導線が用意されています。また、ドメインが参照されていない場合は短時間で削除できる一方、参照が多いと数時間〜1日程度かかることがある、といった目安も案内されています。ドメインの手動削除が必要な場合はサポートが支援する旨も記載されています。
Microsoft 365 管理センターでは「確認済み」なのに Entra ID では進まない理由
ここが一番混乱しやすいポイントです。現象としては次の2パターンが多いです。
- 管理画面のテナントが違う：Microsoft 365 管理センターで見ているテナントと、Entra 管理センター／Azure ポータルで見ているテナントが一致していない。
- バックエンド反映のタイムラグ：追加・削除直後で、検証状態の反映や DNS 参照が遅れている。
後者については、公式にも「伝播は即時の場合もあれば数日かかる場合もある」旨が記載されています。特にレジストラ側の TTL が長いと、修正しても「しばらく前の情報」を世界中が参照し続けるため、検証が通るまで時間がかかります。
補足：Power BI などの“未管理（unmanaged）ディレクトリ”が原因のこともある
Microsoft Learn では、カスタム ドメインが検証できない原因の一つとして「未管理の Power BI テナント（unmanaged directory）」が存在する場合を挙げています。ユーザーがセルフサービス サインアップでクラウドサービスを使うと、組織のメール ドメインを元に“影のディレクトリ”が作られることがあり、これがドメイン重複を引き起こすことがあります。
この場合は「管理者による takeover（引き継ぎ）」という公式手順が用意されており、内部 takeover / 外部 takeover のどちらで回収するかを選べます。検証がどうしても通らないときは、「旧テナント」だけでなく「未管理ディレクトリ」という第三の置き場所も疑うと、ハマりどころが減ります。
短期回避策：サブドメインで先に進める（要件次第）
もし「ルートドメイン（syntralyn.nz）はすぐに解放できないが、サービスを先に動かしたい」場合、要件によってはサブドメイン（例：id.syntralyn.nz や corp.syntralyn.nz）を新テナントで検証して使う方法があります。
Microsoft Learn では、ルートドメインが別テナントに存在していても、サブドメインは別テナントで検証できるケースがあることが記載されています（ただし、用途によってはルートドメインが必要です）。一時しのぎとしては有効ですが、最終的に @syntralyn.nz の UPN やメールを使いたいなら、結局ルートドメインの解放が必要になります。
再発防止：テナント廃止・移行時にやっておくべき「ドメイン衛生」
今回のようなトラブルは、テナント廃止や移行のタイミングで「ドメインを外し忘れる」ことで起きがちです。次のチェックリストを運用に組み込むと、将来の“ドメイン詰まり”をかなり減らせます。
| 廃止前にやること | 狙い |
|---|---|
既定ドメインを onmicrosoft.com に戻す | 削除作業中に管理者が締め出される事故を防ぐ |
| ユーザー・グループ・アプリの参照を棚卸し | ドメイン削除のブロッカーを事前に潰す |
| Exchange 由来（配布リスト等）の参照も確認 | Entra 側だけ触っても残る参照をなくす |
| 削除完了までの時間を見込む（数分〜数時間/最大24h） | 移行当日の “想定外の待ち” を避ける |
ドメイン削除が非同期で進み最大 24 時間かかり得る点や、Microsoft 365 側でも参照が多いと削除に時間がかかる点は、公式ドキュメントにも記載があります。
まとめ：syntralyn.nz を新しい Entra ID で検証できる状態にするには
- まず、Microsoft 365 管理センターと Entra 管理センターで「同じテナント」を見ているかを確認する
- 次に、TXT レコードが外部から正しく引けるか（値・場所・重複・TTL）を検証する
- DNS が正しいのにダメなら「別テナントに既に検証済み」を疑い、旧テナントでドメイン削除（または ForceDelete）を実施する
- 旧テナントを削除済み／アクセス不能なら、サポート チケットで Data Protection チームにドメイン解放を依頼する
実際には、DNS 伝播やバックエンド反映の遅延で、時間を置いて再検証したら通るケースもあります。とはいえ「ドメインの重複（別テナント保持）」だけは待っても解決しないため、OpenID 設定の確認やテナント ID の突合で早めに切り分けるのが近道です。
コメント