简单说，TXT 记录就是你域名在互联网"电话簿"里的一块公开"公告/备注栏"——一段可以自由填写的文字。它最常见的两个用途，一是域名验证（证明"这个域名真的是你的"），二是存放你的邮件安全规则（SPF、DKIM、DMARC）。当 Google 或 Microsoft 365 让你"加一条 TXT 记录来验证域名"时，读完这一篇，你就知道那是什么、安不安全、会不会泄露公司信息，也知道该把这件事交给谁去做，省得自己对着一串看不懂的字符发愁。
这篇文章适合谁看？ ❓
如果你有公司域名、用着企业邮箱，又遇到过下面任意一种情况，这篇值得看：Google、Microsoft 或某个第三方服务让你"加一条 TXT 记录来验证域名所有权"；或者你听说过 SPF、DKIM、DMARC，却不知道它们到底放在哪里、为什么和"域名"有关。如果你没有自己的域名、也不打算用企业邮箱，可以跳过这一篇。
先说为什么会有 TXT 记录
要理解 TXT 记录，得先回到 DNS。DNS（域名系统）是互联网的电话簿：你给它一个好记的域名，它帮你查出服务器真正的数字地址，访客才连得上。想把这本电话簿和它的其他常用栏目一起搞懂，可以看我们关于 DNS 记录 的文章。
电话簿里，A 记录登记"网站在哪台服务器"，MX 记录登记"邮件送到哪个收发室"。但人们还想在自己这条登记下面附一段普通的文字说明——既不是地址，也不是号码，就是一段任何系统都能读到的备注。早期的 DNS 没有这样一个通用栏目，于是 TXT 记录被设计出来，专门在域名上挂一段自由格式的文字。它本来只是个"想写什么写什么"的栏目；后来大家发现这块公开、人人可查、又只有域名主人能改的地方特别好用，就把两件重要的事放了进来：域名验证和邮件安全规则。
一条 TXT 记录长什么样
在域名管理后台里，一条 TXT 记录通常由三部分组成。看懂这三栏，你再打开自己的控制台就不会发懵：
- 主机/名称（Host / Name）：这条记录挂在域名的哪个位置。对整个根域名生效时，通常填一个"@"；某些用途（比如下面会讲到的 DKIM）则会要求填一个特定的前缀（叫"选择器"）或子域名。
- 值（Value）：一段用引号括起来的自由文字，这才是记录真正的内容——验证字符串、邮件规则，都写在这一栏。
- TTL：这条记录可以被各地服务器缓存多久。改动之后，旧值要等缓存到期才会在各地陆续换成新值。
提醒一句：不同服务商对这几栏的叫法不完全一样——"主机"有的写作"Name"或"Host"，根域名有时是"@"有时干脆留空，"值"也可能叫"Value""Content"或"TXT Value"。名字不同，填的东西是一回事。
Google / Microsoft 让我加的那条 TXT 记录，到底是什么
最常见、也最贴近这个问题的例子，是用 Google Search Console（谷歌站长工具）做域名验证。当你在里面添加一个"域名"资源时，Google 会发给你一段类似 google-site-verification=AbC123… 的值，让你把它发布到域名根部的 TXT 记录里。随后 Google 会去查你这个域名的 DNS，一旦读到这段值，就确认你确实掌控这个域名——验证通过。这和"对方寄给你一张专属回执，你把它贴到自家门口的公告栏上，他再过来看一眼确认是你"是一个意思。Microsoft 365 以及很多其他服务，用的也是同一套 TXT 验证套路。
这样做安全吗？会泄露什么吗？
这一点最该说清楚，也最能打消顾虑：那段验证值只是一串公开的文字，把它发布出去既不会给任何人开门，也不会泄露任何敏感信息。具体来说：
- TXT 记录本来就是设计成公开可查的——任何人都能查到任意域名的 TXT 记录，这是正常工作方式，不是漏洞。
- 那段验证字符串对外人没有任何意义，也不包含你公司的任何机密信息；读到它的人，并不能因此登录你的邮箱、网站或后台。它只能证明"域名归你"，不能用来访问任何东西。
- 真正的安全关口，在于谁能修改你的 DNS（也就是谁握有域名管理后台的账号），而不在于这段公告别人能不能看到。
所以，按 Google / Microsoft 的指示添加一条验证用的 TXT 记录，本身是安全的常规操作。需要谨慎的不是"加这条记录"，而是那封要求你加记录的邮件是不是真的来自官方——而这，正好是 TXT 记录的另一个用途要解决的问题。
在 GoDaddy 上大致是怎么加的
各家域名后台的界面略有差异，以常见的 GoDaddy 为例，添加一条验证用的 TXT 记录大致是这样：进入域名的 DNS 管理页，点"添加记录"（Add record），"类型"选 TXT，"名称"（Name）填"@"，"值"（Value）粘贴对方给你的那串字符，保存即可。整个过程不改动别的记录，也不影响网站和邮件的正常运行。
另一个大用途：邮件安全规则就住在 TXT 记录里
除了域名验证，TXT 记录还是三套邮件安全规则的存放地。这三套规则合起来，相当于给你公司发出去的邮件盖上一个"防伪公证章"——让收件方的邮件系统能核实"这封信确实从你公司域名发出，不是骗子冒名顶替"。它们不是独立的新栏目，而是以特定格式写进 TXT 记录里的文字：
- SPF：在 TXT 记录里列出"哪些服务器有资格用我的域名发邮件"，相当于一份授权名单。它怎么写、怎么影响投递，我们在 SPF 的文章里讲得更细。
- DKIM：给每封邮件附上一个加密签名，收件方用同样写在 TXT 记录里的公钥来核对，确认邮件中途没被篡改、确实来自你的域名。这一套的来龙去脉，可以读我们关于 DKIM 的文章。
- DMARC：在 TXT 记录里设定一条策略，告诉收件方"如果有人冒用我的域名发信、又没通过上面两道检查，该怎么处理"。想了解怎么定这条策略，可以看我们关于 DMARC 的文章。
这三者配合，能明显降低别人冒用你公司域名发垃圾邮件、钓鱼邮件的概率，也影响你正常发出的邮件能不能顺利进对方收件箱。它们都不在邮件软件里设置，而是写在域名的 TXT 记录里——这也是为什么"配置邮件安全"听起来和邮箱有关，做起来却要动 DNS。
一个容易踩空的细节
还有一点常让人白忙一场：一条 TXT 记录，只有写在你的"名称服务器"（Name Server）实际指向的那家 DNS 服务商那里，才会真正生效。很多域名虽然在某家注册商名下买的，DNS 却交给了另一家（比如 Cloudflare）托管。这时你若在注册商后台改 TXT，记录看似加上了，外界却查不到、验证也一直不通过。换句话说，要改对地方，先得弄清楚这个域名的记录到底归谁管——这也是交给熟悉你域名设置的人来做更省心的原因之一。
所以你该怎么应对
你不需要自己研究怎么把一段字符串填进 DNS。对非技术的企业老板来说，最稳妥的做法很简单：当 Google、Microsoft 或任何服务商要求你"添加一条 TXT 记录来验证域名"时，把那封邮件原样转发给负责你网站和域名的技术服务方去处理。如果不确定那封邮件是不是真的来自官方，更应该先找人核实，而不是照着陌生邮件里的链接动手——毕竟冒名顶替正是邮件安全要防的事。
5U Website 怎么帮客户处理
域名验证和邮件安全这类配置，属于"配好了没人注意、配错了邮件就大面积进垃圾箱甚至发不出去"的事。在过去近二十年的网站与托管工作里，我们替客户处理过大量企业邮箱接入（Google Workspace、Microsoft 365）和 SPF / DKIM / DMARC 设置。我们的做法是：动 TXT 记录前先确认要求来源是否可信、看清该域名的 DNS 到底由谁托管，再按服务商规范填写并复核。
把这件事交给我们
不必为一条看不懂的 TXT 记录费神——这正是我们的日常工作。5U Website 的网站设计、制作及托管服务里就包含域名验证与邮件安全（SPF / DKIM / DMARC）的配置与维护。如果你收到要求添加 TXT 记录的通知，或者企业邮件出现"发不出、收不到、总进垃圾箱"的情况，给我们写一封邮件，我们通常会在一到两个工作日内回复。
最早发布于：，最近一次编辑时间：
