この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft LearnのMicrosoft 365ドメイン設定とPowerShellのDNS問い合わせ方法を確認し、「TXTを登録したのにMicrosoft 365で確認できない」ときの切り分け手順に焦点を当てています。検証ステータス：📘 Microsoft公式確認済み・tenant変更なし
Microsoft 365のドメイン所有権確認でTXTを登録しても、すぐ確認できないことがあります。
このとき「待てばよい」で終わらせず、どのDNSへ問い合わせると、どの値が見えているかを確認すると原因を切り分けやすくなります。
1. まず普段使っているDNSから確認する
$domain = 'example.com'
Resolve-DnsName -Name $domain -Type TXT |
Select-Object Name, Strings, TTL
Microsoft 365管理センターで指定された MS=msXXXXXXXX が見えるか確認します。
実際の値は必ず管理センター表示を使います。
2. 権威DNSを確認する
そのドメインのNSレコードを確認します。
Resolve-DnsName -Name $domain -Type NS |
Select-Object NameHost
ここに表示されるのが、公開DNSの正本を持つ権威DNS候補です。
3. 権威DNSへ直接問い合わせる
$ns = (
Resolve-DnsName -Name $domain -Type NS |
Select-Object -First 1 -ExpandProperty NameHost
)
Resolve-DnsName -Name $domain -Type TXT -Server $ns |
Select-Object Name, Strings, TTL
権威DNSでは新しいTXTが見えるのに、普段のDNSでは古い結果なら、キャッシュや反映時間の影響を疑えます。
どこまで反映しているかを分けて考える
flowchart LR A[DNS管理画面へTXT登録] --> B[権威DNS] B --> C[再帰DNS/キャッシュ] C --> D[自分のPC] B --> E[Microsoft 365の確認]
「管理画面へ登録した」はAの完了です。
しかし実際の確認では、
Bに正しい値があるか
Cが新しい値を返すか
Microsoft 365側から取得できる状態か
を分けて考えます。
4. TTLを見る
DNS応答にはTTLがあります。
TTLはキャッシュがその応答を保持できる時間の目安です。
変更直後に古い値が残る場合、TTLやDNS事業者側の反映処理が関係することがあります。
ただし「TTLが300だから必ず5分で全世界反映」と単純には言えません。各DNSホストの反映やキャッシュ状態もあるため、公式案内と実応答の両方を確認します。
5. よくある設定ミス
名前を間違えた
DNS事業者によって、root/apexを
@空欄
ドメイン名そのもの
など異なる形式で入力する場合があります。
別のDNS事業者を編集した
ドメインを取得した会社と、実際の権威DNSを提供する会社が違うことがあります。
「ドメイン管理画面にTXTを入れた」つもりでも、実際のNSが別サービスなら公開DNSへ出ません。
値が違う
MS=msXXXXXXXX は推測せず、Microsoft 365管理センターに表示された値と照合します。
仕事でどう使えるか
この切り分けはM365だけでなく、
SaaSのドメイン所有権確認
SPF
DKIM
DMARC
Search Console
証明書DNS認証
でも同じ考え方を使えます。
「サービスが認識しない」という問題を、サービス側・権威DNS・キャッシュDNS・端末のどこで止まっているかに分けられるのが実務上の価値です。
注意点
社内限定DNS名や内部サーバー名を記事・AIへ貼らない
Microsoft 365の実TXT値を公開ログへ載せる必要はない
DNS変更はメール配送等にも影響し得るため、TXT以外のレコードを不用意に変更しない
所有権確認後のTXT削除可否はMicrosoftの最新手順に従う
まとめ
DNS管理画面への登録と公開DNSで見えることは別
NSを調べると権威DNSを確認できる
権威DNSへ直接TXT問い合わせするとキャッシュ問題を切り分けやすい
TTLは判断材料だが、単純な反映完了時刻ではない
M365以外のDNS認証トラブルにも同じ考え方を使える
