关于本文
本文采用基于生成式 AI 的自动化流程创建。我们参考了 Microsoft Learn 中的 Microsoft 365 域设置和 PowerShell 的 DNS 查询方法，重点介绍了“已注册 TXT 记录但在 Microsoft 365 中无法验证”时的排查步骤。验证状态：📘 Microsoft 官方已确认 · 租户未变更
在 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 验证故障
