TXT记录是DNS解析体系中最容易被忽视却又使用频率极高的一类记录。当你注册企业邮箱需要配置SPF防伪验证、接入第三方服务需要证明域名所有权、或者部署邮件签名加密策略时，几乎都绕不开TXT记录的查询与配置。不少人在操作时发现配置了记录却查不到、或者查出来的内容和设置的不一样，其实多半是对TXT记录的特性和查询方法不够了解。本文将从原理、查询方法、常见问题三个层面，把TXT记录这件事彻底讲清楚。
一、TXT记录是什么，它到底能干什么
简单来说，TXT记录就是允许域名管理者在DNS中存放一段文本信息的外部接口。这段文本对外完全公开，任何人都可以通过DNS查询获取。听起来似乎没什么特别，但正是这种公开可验证的特性，让TXT记录成为域名身份证明的事实标准。
目前TXT记录最常见的用途包括以下几种：一是SPF反垃圾邮件声明，通过 v=spf1 include:spf.mail.qq.com ~all 这样的语句告诉收件方服务器哪些IP被授权发送本域名的邮件；二是DKIM公钥存储，用于邮件签名验证；三是域名所有权验证，比如申请SSL证书、接入百度站长平台、微信开放平台时，服务商会要求你添加一条特定内容的TXT记录，他们查到这条记录就证明域名归你所有；四是存储一些安全策略信息，如DMARC配置、验证码等。
需要理解的一点是，TXT记录本身不参与域名到IP的转换，它不会影响网站访问。它只是挂在某个主机名下的一串文本，查询时通过特定的查询类型去读取。这也是为什么很多人用普通方式查DNS发现一切正常，却始终找不到TXT记录的原因——查询方式不对。
二、三种常用的TXT记录查询方法
1. 使用nslookup命令（Windows和Linux通用）
nslookup是系统自带的DNS查询工具，Windows用户无需安装任何软件，打开命令提示符（cmd）直接输入即可。查询TXT记录需要先指定查询类型为TXT，操作命令如下：
nslookup -type=TXT ippipp.com # 或者进入交互模式 nslookup > set type=TXT > ippipp.com
执行后如果域名存在TXT记录，会返回类似 "v=spf1 include:spf.mail.qq.com -all" 的文本内容。注意返回的文本通常被双引号包裹，这是正常现象，不代表记录里包含了引号。如果没有返回任何TXT信息，系统会提示找不到该类型的记录，这时就要检查记录是否真的添加成功了。
2. 使用dig命令（Linux和macOS推荐）
dig是功能更强大的DNS查询工具，在Linux和macOS上默认可用，Windows用户可以单独安装。查询TXT记录只需一条命令：
dig TXT ippipp.com +short # 查询指定DNS服务器，例如直接问8.8.8.8 dig @8.8.8.8 TXT ippipp.com +short # 不加short参数可查看完整应答详情 dig TXT ippipp.com
+short 参数会只输出记录内容，便于快速查看；不加该参数则会显示完整的应答信息，包括TTL值、权威服务器等，排查解析问题时更实用。通过 @8.8.8.8 指定查询公共DNS服务器，可以对比本地DNS缓存的结果，判断记录是否已经全球生效。
3. 使用在线查询工具
如果嫌命令行麻烦，也可以使用在线DNS查询平台，例如站长之家的DNS查询、Google的DNS查询工具、各云厂商提供的解析检测页面。操作方式基本一致：输入域名，选择记录类型为TXT，点击查询即可。在线工具的优势在于可以自由切换查询节点，方便检测不同地区的解析生效情况，同时能直观看到多条TXT记录的完整列表。
三种方式各有适用场景：临时快速验证用在线工具，日常运维排查建议用dig，Windows环境下nslookup最顺手。无论用哪种方式，查询时务必确认查询的类型选的是TXT，而不是默认的A记录。
三、查询TXT记录的常见问题与注意事项
1. 刚添加的记录查不到是怎么回事
DNS记录存在TTL（缓存生存时间）机制，新添加的记录需要经过一个传播过程才会全球可见。一般在各大DNS服务商处添加TXT记录后，几分钟到十几分钟内就能查询到，但如果本地DNS或者运营商DNS存在缓存，可能需要更长时间。解决办法是查询时指定权威DNS服务器，绕过中间缓存直接确认记录是否已经写入：
dig TXT ippipp.com @ns1.dnsv1.com +short
如果权威服务器上已经能查到，说明只是缓存未刷新，耐心等待即可；如果权威服务器上也查不到，就要回到DNS控制台检查记录是否保存成功。
2. 主机记录填错导致查不到
这是新手最高频的踩坑点。TXT记录是挂在具体主机名下的，域名所有权验证时服务商通常会告诉你添加一条主机记录为 _dnsauth 或类似值的TXT记录，完整域名实际是 _dnsauth.ippipp.com。如果在控制台把整个 _dnsauth.ippipp.com 填进了主机记录栏，实际生成的就是 _dnsauth.ippipp.com.ippipp.com，自然查不到。同理，验证根域名时主机记录应该留空或填写 @，而不是再填一遍域名本身。
3. 字符长度限制与记录值被拆分
单条TXT记录中每一段字符串不能超过255个字符，超出部分会被自动拆分成多个带引号的字符串。DKIM公钥这类长内容经常触发这个限制。查询时会看到返回值被引号分成好几段，这是DNS协议的正常表现，拼接起来就是完整内容，并不是记录损坏。配置时如果服务商支持，建议使用2048位以下的密钥或让服务商自动分段，避免手动拼接出错。
4. 多条TXT记录共存的情况
同一个主机名下可以同时存在多条TXT记录，比如SPF和域名验证记录并存。但需要注意的是，SPF规范要求一个域名只能有一条SPF记录，如果出现两条 v=spf1 开头的记录，对方的校验会直接失败。多条SPF需求应该合并写法，例如把多个include写在同一条记录里，而不是分成两条添加。
四、总结
查询域名TXT记录本身并不复杂，核心在于选对工具、指定对记录类型、查对主机名。日常工作中建议养成一个习惯：添加记录后先通过 dig @权威服务器 确认记录写入成功，再用本地查询观察传播进度，最后到第三方平台做验证，这样基本可以覆盖所有TXT相关的排查场景。遇到查询不到的情况，按照检查主机记录拼写、确认记录类型、等待缓存刷新这三步走，绝大多数问题都能快速定位。掌握这些方法和细节，域名TXT记录的查询与排查就不再是难题。