TXT记录不是用来给网站指路或加速的，它的核心用途是给域名挂一段可公开查询的文本，让验证方、收信方或某个服务来读取。搜这个问题的人通常已经拿到一条“请添加TXT记录”的指引，想确认它到底解决什么、会不会影响现有解析、以及填完怎么验证。先看对方是否明确要求记录类型为TXT，再看你有没有该域名的DNS编辑权限；两件事都成立，才需要继续操作。
收到“添加TXT记录”的验证或邮件认证指引时，TXT记录就是需要配置的对象；如果目标是网站访问、邮件收信路由或页面跳转，TXT记录通常不承担这些功能。操作时确认主机记录、记录值和TTL，用dig分别查权威DNS与递归DNS；不要把同一条记录的多段字符串误当成多条记录，也不要在SPF场景下保留两条v=spf1记录。
TXT记录到底指什么
TXT记录是DNS中类型为TXT的资源记录，值是一段文本。它解决的问题是：让域名下某个名称公开携带一段字符串，供域名归属验证、SPF/DKIM/DMARC邮件策略或第三方服务校验读取。这个场景成立的前提是：你拥有该域名的DNS管理权限，并且对方明确给出了记录名（主机记录）和记录值。DNS服务商控制台里通常看“解析记录/DNS Records”页，字段包括记录类型、主机记录、记录值、TTL；命令行可以这样核对（把example.com换成你的域名）：
# 查裸域TXT
dig +short TXT example.com
# 查DMARC和某个DKIM选择器
dig +short TXT _dmarc.example.com
dig +short TXT default._domainkey.example.com
# 看完整答案和TTL
dig +noall +answer TXT example.com判断顺序可以先按下面这张清单走：
- 对方是否明确要求“TXT记录”，而不是CNAME、A或MX？
- 记录名是填@、子域名，还是带_dmarc、_domainkey的完整名称？以验证页给出的主机记录为准。
- 记录值是原样复制，还是被面板自动加了引号？先保存，再用dig看实际返回。
- 同一名称下是否已有TXT记录？新增前先查，避免SPF等策略出现重复。
- 保存后分别查权威DNS和递归DNS；不一致时先等TTL过期，再判断是否填错。
TXT记录和哪几个说法容易混
名字里带“记录”的东西很多，容易把TXT记录和邮件认证记录混成一件事。下面按“实际类型”和“一眼分辨条件”摆开：
| 说法 | 实际是什么 | 一眼分辨 |
|---|---|---|
| SPF记录 | 实际是TXT记录，值以v=spf1开头 | 执行dig +short TXT example.com，看到v=spf1才是SPF；DNS类型里通常没有单独的SPF可选项，有些面板只是提供模板，落地仍是TXT。 |
| DKIM记录 | 通常是TXT记录，名称形如选择器._domainkey.example.com | 看主机记录是否包含._domainkey，值里是否有v=DKIM1和p=公钥。 |
| DMARC记录 | 是TXT记录，名称固定为_dmarc.example.com | 看名称是否为_dmarc，值是否以v=DMARC1开头。 |
| 域名验证TXT | 平台生成的一串token，名称可能是@或_xxx | 值通常没有v=spf1、v=DKIM1、v=DMARC1前缀，验证页给什么就填什么。 |
| CNAME记录 | 别名记录，不是TXT | 记录类型是CNAME，dig查询会返回CNAME目标；同名位置不要同时放CNAME和TXT。 |
最容易踩的坑是把同一条TXT记录的多段字符串当成多条记录。DNS返回 v=spf1 ... 和 include:... 两个带引号的片段时，它们通常属于同一条记录，验证时应按顺序拼接；如果dig输出两行都以v=spf1开头，才是两条SPF记录，需要合并或删除多余的一条。另一个相反错误是在面板里为了“保险”新增两条相同TXT，导致验证方读到重复值。
什么情况其实用不上TXT记录
以下场景通常不需要TXT记录，或者不该用TXT记录解决：
- 让域名访问网站：用A/AAAA指向IPv4/IPv6，或用CNAME指向另一个域名；TXT不参与HTTP访问。
- 指定邮件收信服务器：用MX记录；SPF、DKIM、DMARC是发信认证策略，不负责把邮件投到哪台服务器。
- 做页面跳转或路径跳转：在Web服务器、CDN或对象存储的跳转规则里配，TXT记录做不到。
- 存业务配置、大段JSON或频繁变更的数据：TXT值受单段字符串长度、面板输入框和DNS服务商套餐限制，不适合当配置中心。
- 没有域名DNS编辑权限：不要绕开权限去改；找域名管理员，或看验证方是否提供HTML文件、CNAME等其他验证方式。
判断依据可以落到权限和套餐上：在DNS服务商控制台的“解析记录”页确认是否出现TXT类型、当前套餐是否允许添加、是否有条数或API限制；这些会随服务商和套餐变化，不能凭记忆判断。只做一次性验证时，还要看验证方是否要求长期保留记录，别验证完就删。
TXT记录：三个动作确认你真的搞懂了
动作一：查权威DNS和递归DNS是否一致。把NS地址换成你的DNS服务商实际分配的地址：
dig +short TXT _dmarc.example.com @8.8.8.8
dig +short TXT _dmarc.example.com @ns1.example.net预期结果：两条命令都返回相同的v=DMARC1开头值。只有权威DNS有、递归DNS没有，通常是缓存未过期或TTL较长，可以先等待再查；两边都没有，优先检查记录名和保存状态。
动作二：确认最终记录名没有多写或少写域名。
dig +noall +answer TXT _dmarc.example.com预期结果：答案行的名称是_dmarc.example.com.，类型是TXT，值是DMARC策略。如果答案为空，说明主机记录可能填成了_dmarc.example.com.example.com，或者记录保存在别的子域；如果名称对但值不对，回到验证页逐字比对。
动作三：确认多字符串和重复记录。
dig +short TXT default._domainkey.example.com预期结果：返回一条DKIM公钥记录，可能被拆成多个带引号的字符串，拼接后应包含v=DKIM1和p=。如果看到两条都以v=DKIM1开头，说明同一选择器下有多条记录，需要清理；如果返回空，先确认选择器名称是否来自邮件服务商给出的默认选择器。