域名验证记录只能加不能删，130个站平均挂着14条

摘要：把131个英文大站的域名根拿DNS查了一遍，130个站的根域上挂着2363条TXT记录，其中1880条是第三方服务的域名验证记录，来自157家不同的服务。平均一个站14.5条，最多的一个67条。130个站里有116个把同一家服务验证过两遍以上，最狠的一个站给同一家邮件营销工具挂了16条。有27条记录自己带着日期，最早那条写于2021年5月，到今天还在。而这一切不是因为运维懒——Google的官方文档白纸黑字写着“验证通过之后也不要删掉这条记录”。

接一个新工具的时候，多半有这么一步：对方给你一串字符，让你去DNS后台加一条TXT记录，加完点“验证”，绿灯亮了，事就算成了。整个过程五分钟。

然后这条记录就留在那儿了。半年后换了工具，一年后换了代运营，三年后当初加它的人早已离职。它还在。

保哥这回把131个英文大站的域名根挨个查了一遍，只想弄清一件事：这些年攒下来的记录，到底攒了多少。

这一轮把什么东西翻出来了？

查的对象是域名根上的TXT记录。这类记录不影响网站能不能打开，页面上也看不见，属于典型的“没人会主动去看一眼”的地方。但它承载着一件很重的事——向第三方证明这个域名归你。

131个站里，130个的根域上至少有一条TXT。唯一的例外是bonprix.com，一条都没有。这130个站一共交出2363条记录，我按内容把它们分成四类：

四类里最值得说的是第一类和第二类。第一类是本篇的主角，第二类稍后单独讲——那278条谁都认不出的字符串，本身就是个不小的问题。

先说口径。这轮抓取从中国大陆的网络发起，DNS查询走的是Cloudflare的DNS over HTTPS接口。为什么强调这个，下面讲尺子那一节会给出理由，那是本轮最先踩到的坑。

一个域名根上到底挂着多少条？

1880条验证记录，摊到130个站头上，平均每站14.5条，中位数12条。但均值在这里意义不大，因为少的极少、多的极多：

迪卡侬那67条是本轮的天花板。一个域名根上挤着67条验证记录，来自29家不同的服务。你可以把它想成一间办公室的门口挂着29家公司的铜牌，其中有些公司还挂了好几块。

157家服务这个数字也值得停一下。它意味着这130个品牌在过去若干年里，前后跟至少157家外部服务建立过“我拥有这个域名”的关系。搜索引擎、社交平台、邮件工具、办公套件、设计工具、支付网关、证书机构、设备管理、安全审计——一整条SaaS采购史，全刻在这一个位置上。

出现最多的十五家是这样：

Google覆盖125个站，也就是说只有5个站的域名根上没有Google的验证记录。这个不奇怪，Search Console是标配。

真正让人意外的是名单里那三家AI公司。Anthropic出现在45个站上，OpenAI 24个，Cursor 11个。这三家的域名验证记录在两年前还不存在，现在已经铺到三分之一的头部品牌上了。这几家的爬虫该不该放进来是另一个话题，拦不拦AI爬虫要从robots、UA到WAF分三层想；但域名验证这一层是先于抓取发生的，它决定的是谁能以你的名义调用接口。DNS记录成了一份不撒谎的采购时间表——公司买了什么、什么时候买的，营销部门可以不说，这里瞒不住。

另一头是长尾：157家服务里有65家只出现过一次。一个站接了一个别人都没接的工具，留下一条别人都没有的记录。

这些记录里，认得出主人的有几条？

能认出主人的前提是记录里写了名字。绝大多数服务确实写了，写法也很统一，`厂商名-domain-verification=一串值`，一眼就知道是谁。

但有278条不是这样，占全部记录的11.8%，分布在64个站上——也就是每两个站里就有一个，域名根上挂着看不出来历的字符串。它们长这样：

_uwa8l4amfi15ok42t5778dbyawkrwbd
0ed1fe018aeb71f25a5297419296150b
8rlnys07lnz6xvr7wsr4zg0kkz8yd6d5

没有厂商名，没有前缀，没有任何提示。你把它删了，可能明天某个系统就开始报错，也可能什么都不会发生——在删之前你没有办法知道是哪一种。

不过这些串并非完全无从下手。把它们按前缀归一遍，能看出些门道：

• 以0ed1fe018a开头的串出现在7个互不相干的品牌上——瑜伽服、床垫、床品、美妆电商、运动鞋、地毯、保温杯。同一家服务，同一套前缀，只是它没在记录里写自己叫什么。
• 以下划线打头、后面跟31位小写字母数字的形态，出现在22个站上，格式完全一致。同样认不出是谁。下划线打头这个习惯本身是有来历的——RFC 8552专门规定了带下划线的名字该怎么用，就是为了不让各家挤在同一个位置上互相踩；哪些前缀是正式登记过的，可以查IANA的DNS参数注册表。这22条查不到。
• 2tlqwxywz1这个前缀只出现在两个站上：fiskars.com和iittala.com。这两个牌子本来就属于同一个集团，同一批人办的事，拿到的凭据前缀自然一样。

换句话说，你能推断出“这22个大牌用的是同一家服务”，却推断不出那家服务叫什么。这种记录最难处置：留着不知道在给谁开门，删了不知道会碰倒什么。

关于TXT记录里怎么放“属性=值”，RFC 1464早在1993年就给过写法建议。后来各家服务确实都往这个方向靠了，但没有任何机制强制谁必须署名。署不署名，全凭自觉。

为什么同一家服务要验证十几遍？

本轮最扎眼的数字在这里：130个站里有116个，至少有一家服务被验证过两遍以上，占比89.2%。

重复得最厉害的几组是这样：ugreen.com给Klaviyo挂了16条，harrys.com给Stripe挂了15条，decathlon.com给Google挂了12条，dreametech.com的Klaviyo 11条，chubbiesshorts.com的Google也是11条。

一个域名给同一家邮件营销工具挂16条验证记录，这件事没法用“业务需要”解释。这轮的数据只能看到结果，看不到过程，所以下面三种成因是从记录形态倒推的，不是统计出来的：

最常见的一种是每个账号一条。Google的验证令牌是绑账号的，市场部的人验一次，SEO代理商验一次，新来的运营再验一次，就是三条。而按Search Console对所有者身份的定义，用令牌验证过的人叫“已验证所有者”，他可以直接把别人任命为“委派所有者”，权限一模一样，还不需要自己的令牌。所以一条记录背后可能跟着好几个人。

第二种是每个环境一条：测试账号验一次，正式账号验一次，欧洲区再验一次。

还有一种是验证失败之后重来。第一次填错了，重新申请一串新的填进去，旧的那串没删。这类最隐蔽，因为两条看起来一模一样，谁也不敢确定哪条是活的。

迪卡侬那12条Google验证记录，大概率是十几年间不同团队、不同代理商、不同区域各自留下的。每一条当时都有用，现在有几条还有用，恐怕连他们自己也说不清。

有些记录自己带着出生日期，最老的写于哪一年？

大部分验证记录是一串随机值，看不出年龄。但有一小撮服务在生成令牌的时候把时间也写了进去。这轮抓到27条这样的记录，来自16个站。

Figma的写法是64位十六进制后面挂一个Unix时间戳：

figma-domain-verification=b5b1f3bf...171f206-1780476658

Fastly更直接，把日期明文写在串里。Arc'teryx一家就有5条，摆在一起看很说明问题：

fastly-domain-delegation-7NS9BXcjeGQwdNVfew6mpF-365474-2021-05-07
fastly-domain-delegation-233sddF-367821-2021-05-12
fastly-domain-delegation-BjR4sGFIcG-421314-2021-07-15_of_today
fastly-domain-delegation-S93rtg37dumgAejysS6q-453873-12152021
fastly-domain-delegation-qzbB9m4S37}_-2024-09-18

五条记录，从2021年5月排到2024年9月，一条都没删。而且这五条里能读出三桩小事故：第三条尾巴上挂着 _of_today，模板占位符没替换掉就提交了；第四条的日期突然换成了12152021这种月日年连写的格式；第五条的值里混进一个反花括号。没有一条被发现，因为根本没有人会回头看这个地方。

Ouraring的两条Mosyle记录，时间戳分别指向2025年3月和2026年2月，相隔11个月。加第二条的时候第一条还在，加完之后第一条依然在。

最完整的一条来自Suitsupply，它把ISO格式的时间精确到秒写进了记录，还在一条TXT里塞了两个等号：

fireflies-verification=01KQW89D87FTZTS14807YEBDHR.ffverify.fireflies.ai-request-verification=2026-05-05T14:22:19Z

把27条按时间排开，最早的一条是Arc'teryx那条2021年5月7日的Fastly记录，到这一轮抓取的时候已经在那里待了五年多。这还只是能读出日期的那部分。剩下1853条没写日期的记录里，比这更老的几乎肯定存在，只是没法证明。

一条验证记录到底把什么交出去了？

讲到这里得把“这只是一串没用的字符”这个印象掰过来。

以Google为例。Search Console有两种资源类型：网址前缀资源和网域资源。网域资源只能用DNS TXT记录验证，而它一旦验证成功，覆盖的是这个域名下所有协议和所有子域的数据，官方原话是“include data for all protocol (http/https) and subdomain variations of your property”。所有子域，包括那些你早就忘了的。子域名和子目录在权重上怎么算是另一回事，在权限上它们全算一家。

这句话翻译成人话：一条TXT记录换来的不是某个页面的数据，是这个域名底下所有东西的搜索表现。哪些词带来了流量、哪些页面在掉、有没有被人工处罚、结构化数据报了什么错，全部打包。这些数字各自该怎么读够单写一篇，这里只说一件事：它们的可见范围是一条TXT记录给的。两种资源类型的区别，在GSC网域资源与网址前缀资源的对比里讲过更细的选型场景。

更要紧的是权限本身会长脚。已验证所有者可以任命委派所有者，委派所有者拥有同样的权限。你在用户列表里把某个人删掉，只是删掉了名单上的一行；只要那条TXT记录还在，持有令牌的那个账号随时可以重新验证一遍，重新回到所有者的位置上。凭据不在名单里，在DNS里。

其他服务各有各的口子。邮件营销平台的验证记录通常和“代表这个域名发信”绑在一起；支付服务的验证记录关联着结算主体；办公套件的验证记录决定了谁能拿这个域名开企业账号。这些不是SEO问题，是资产归属问题，只是它们恰好都住在SEO的地盘上。浏览器判断几个域名算不算同一个站有一套自己的规矩，公共后缀列表划的那条线和验证记录划的线并不重合。

去年有个做户外装备的独立站客户换代运营，新团队问旧团队要GSC权限，旧团队爽快地把账号里的人删干净了。三个月后新团队发现后台里多了一个陌生的所有者，查下来是旧团队的一个员工用当年那条还留在DNS里的令牌重新验证进来的——不是恶意，是他自己也不知道那条记录还在，某次点开Search Console就自动恢复了。清账要清到DNS那一层，只清用户列表等于没清。

既然早就不用了，为什么没人删？

顺着上面的逻辑，正常的反应是：那不用的赶紧删掉啊。

问题在这儿——Google的官方文档里有这么一句：

Important: To stay verified, don't remove the DNS record from your provider, even after verification succeeds.

要保持验证状态，就不要删掉这条DNS记录，验证成功之后也不要删。这句话完全正确，也完全合理：验证是持续性的，Google会定期回来看令牌还在不在，不在就掉验证。

但把它和另外156家服务的同类要求叠在一起，效果就变了。每一家都要你把钥匙永久插在锁孔里，于是域名的锁孔里插满了钥匙，而且没有任何一家会提醒你“我们已经不需要这把了”。加记录有明确的触发点——接新工具的那一刻；删记录没有触发点，停用一个工具的时候，没有人会想到DNS后台。

所以这不是运维懒的问题，是流程上根本没有回收这一步。这个形态在别的地方也见过：页面上的preconnect指着的域名有8个已经不存在了，HTTP响应头里有248个没人读的死字段，robots.txt里35.7%的指令压根没有接收方——都是“加的时候有人负责，撤的时候没人负责”。DNS这一层只是把这个毛病放大到了权限层面。

SEJ在一篇讲AI与网站安全的报道里提到，OpenAI、Anthropic、AWS、Google等一百多家机构联署的公开信把“过度的权限”列在攻击者最容易利用的几类弱点里。那封信给的原则是把访问权限收到最小必要。原则没错，落到具体，第一个要盘的地方大概就是这里——毕竟你的域名根上平均躺着十四把没收回的钥匙，还都是你自己发出去的。

写废了的那几条，会有人发现吗？

既然没人回头看，写错了自然也不会有人知道。这轮从2363条记录里挑出了几条明显写歪的：

迪卡侬那条最惨。globalsign-domain-verification后面本该是等号，实际是字母z，末尾还拖着一个 \010。这条记录GlobalSign永远读不到，等于白写。它在那儿多久了没法知道，反正现在还在。写废的声明在别处也不少见，robots.txt写废一行就能让整站从搜索里消失，只不过那个错会立刻被发现，这个不会。

另外还有一类不算写错、但放错了地方的：7条DKIM公钥被直接挂在了域名根上。DKIM按规矩应该待在 选择器._domainkey.域名 这样的子域下，放在根域既起不了作用，还白白撑大了根域的响应体积。DKIM到底该怎么摆，邮件投递率那篇里有完整的配置顺序。

顺带一提，根域TXT堆太多不是没有代价的。SPF本身有一个10次DNS查询的硬上限，而这个上限往往是被上游服务商替你花掉的；根域记录越多，一次DNS应答越大，越容易从UDP掉到TCP重查。这两件事都不致命，但都属于“本来可以不发生”。

还有一类东西严格说不是验证记录，而是有人拿TXT当便签纸用了。66条，分布在40个站上：

• bollandbranch.com的根域上写着一句英文：ALIAS for n.ssl.shopify.com。这是给同事看的说明，不是给机器看的。
• braun.com挂着三条Azure站点名，其中一条是braun-stage-com.azurewebsites.net——内部环境的命名规则就这么公开了。预发布环境本身是最容易漏进搜索结果的一类资产，而它的名字先从DNS里漏了出来。
• aboutyou.com上有一条OSSRH-61066，那是Java包仓库的一个工单号。一个时尚电商的域名根上，躺着一条开源软件发布流程留下的痕迹。
• anker.com有一条内容就是19.11.2024，shein.com有一条是13.07.2022。有人在这里记了个日期，记的是什么已经无从考证。

域名根上的TXT本来是给机器读的公告栏，用着用着，变成了办公室冰箱门上贴满便利贴的那块地方。

这把尺子错了几次？

这轮的判据改了好几版，每一版都是人工把结果逐条翻一遍才发现问题的。把修正过程写出来，数字才有人敢用。

最先撞上的是工具本身。dns.google在中国大陆稳定超时，一条也拿不到，只能换端点。这一条不影响数字，但它决定了后面所有数字的来源。

第二处最要命：不同的DNS服务器，给的记录条数根本不一样。同一个域名分别问Cloudflare和阿里的DoH接口：

规律很清楚：条数在16条以内的，两边给的完全一致；超过之后，国内这套在17到20条左右封顶，像个只肯背二十个字的传话人。要是拿国内DNS去查自家域名，看到20条就以为盘完了，实际可能漏掉一大半。全篇数字统一以Cloudflare的应答为准，这条也是给读者的实操提醒。

第三处，时间戳差点全判错。最初的正则会从纯十六进制串中间捞出连续10位数字当Unix时间戳，Figma那批记录几乎全被误判成“自带日期”。收紧成“必须由连字符或下划线引出且位于串尾”之后，27条时间证据逐条对完整值核过一遍，全部成立。

第四处，“值里混进反花括号”这个判据的误报率是九成。它命中10条，其中9条是v=spf1 include:%{ir}.%{v}.%{d}... 这样的写法——那是RFC 7208定义的SPF宏，完全合法。真正写错的只有Arc'teryx那一条。

第五处，漏判了七种形态。Fastly的记录全串用连字符连接、根本没有等号；飞书的写法把前缀顺序反过来写成verification-code-site-App_feishu=；还有Salesforce Marketing Cloud的SFMC-、Salesforce组织ID、Mandrill、Cloudflare、微软的v=verifydomain MS=。补进去之后验证记录从1851条涨到1880条。

最后一处不涉及正则，涉及态度：“其他”这一类不能当垃圾桶。剩下那批既不是验证记录也不是纯随机串的东西，塞进验证记录会把数字撑虚，直接丢掉又会漏掉“有人拿TXT当便签”这个真实现象。单独立一类，是这轮唯一一次因为不忍心丢数据而多花的力气。

六处修正里，三处会让数字偏大，两处会让数字偏小，还有一处纯粹是换了个能用的工具。会朝两个方向都出错的尺子，比只朝一个方向出错的更该被公开——第三方工具的数据准不准，判断标准也是同一条。

自己域名上有多少条，怎么查？

不需要装任何东西，一条命令就够。Windows上用nslookup：

nslookup -type=TXT example.com 1.1.1.1

macOS或Linux上用dig：

dig +short TXT example.com @1.1.1.1

末尾那个1.1.1.1别省。上面那张对照表就是它存在的理由——用默认的本地DNS查，很可能只看到实际记录的一半。查完再补两条子域：

dig +short TXT _dmarc.example.com @1.1.1.1
dig +short TXT _domainkey.example.com @1.1.1.1

拿到清单之后，逐条按下面这四个问题过一遍：

1. 它写了厂商名吗？写了的，去查这家服务现在还在不在用。
2. 同一家出现了几次？超过一次的，要弄清是不同账号还是历史残留。
3. 没写厂商名的，能不能靠格式认出来？认不出的，先标记，别急着动。第三方给的默认值会在你不知情的时候自己变，凭印象判断风险很大。
4. 它是不是根本就写废了？等号打成别的字符、多了空格、带着模板占位符的，这类是纯粹的垃圾，删了没有任何风险。判断一条记录是不是真的生效，思路和验证一个爬虫是不是真的Googlebot一样：别信它自称是什么，去查对方认不认。

哪些能删，哪些不能碰？

盘完之后真到动手那一步，按下面这个顺序来，风险从低到高：

还有两件事，比清理本身更值得花力气。

第一件，别指望一次清干净。真正值得建立的是“加记录的时候顺手登记一下”这个习惯：谁加的、为了接哪个服务、哪个账号、什么时候加的。这份登记表放在哪儿都行，重点是它得存在。做过SaaS工具栈盘点的人对这个套路应该不陌生，DNS这一层无非是同一件事的另一个抽屉。

第二件，把它挂到已经在做的事上。你多半已经有一些定期要做的事——证书快到期了要续、GSC里的问题验证完要复核、robots规则改完要确认真的生效了。DNS记录盘点顺着这几件事捎带上，比单独立个项容易活得久。做多国站点的话还得再加一条：域名结构选ccTLD还是子目录决定了你要盘几套DNS，选之前最好把这笔账也算进去。

最后回到那句官方提示。“验证成功之后也不要删”这个要求本身没问题，问题在于它只说了前半句。没有一家服务会告诉你，什么时候可以删。那半句话得你自己补上。补的办法只有一个，就是有人真的打开那份清单看一眼。从89.2%这个数字看，这130个大牌里，多数还没有人看过。

常见问题解答

删掉一条用不上的验证记录，会影响网站排名吗

不会。TXT记录不参与排名计算，搜索引擎也不会因为域名根上记录多就减分。它影响的是权限归属和后台数据的可见范围。真正的风险在于删错——把还在用的那条删了，对应服务的验证会掉，比如Search Console里的资源会变成未验证状态，历史数据看不了，问题通知也收不到。所以清理的顺序应该是先删明显写废的，再删能确认停用的，认不出来历的留到最后。

Search Console显示我是所有者，是不是说明DNS里那条记录还在

不一定。所有者分两种，用令牌验证过的叫已验证所有者，被别人任命的叫委派所有者，后者不需要自己的令牌，权限却一样。反过来那一面更要紧：只要DNS里的记录还在，持有那个令牌的账号随时能重新验证回来。所以做权限交接的时候，光清后台的用户列表不够，得同时核对DNS里有几条对应服务的验证记录。

那些认不出主人的字符串，有办法查出是谁的吗

没有通用办法，但能缩小范围。先看格式，同样的前缀和长度往往对应同一家服务，这一轮就靠这招发现有个十位前缀同时出现在七个不相干的品牌上；再把这个域名接过的服务清单和记录条数对一遍，剩下对不上的就是嫌疑；最后可以在测试域名上重新走一遍各家的验证流程，看谁生成的串长得一样。三步之后还认不出的，登记备案，先别删。

用国内的DNS查自己的域名，为什么条数对不上

这一轮实测到的现象是，记录条数超过16条之后，国内DoH接口返回的条数会在17到20条左右封顶，而Cloudflare会把全部返回，nike.com在两边分别是44条和18条。所以自查时要显式指定解析服务器，dig命令末尾加@1.1.1.1，nslookup把它放在域名后面。这个差异不影响网站正常访问，只影响你看到的完整度。

一个域名的TXT记录太多，会拖慢网站吗

对网页加载几乎没影响，浏览器访问网站查的是A或CNAME记录，不查TXT。真正受影响的是两件事：一是SPF有10次DNS查询的硬上限，记录写法不当容易撞上，而这个额度常常是被上游服务商替你花掉的；二是根域应答体积过大时，DNS查询可能从UDP退回TCP重查一次。两者都不致命，但都属于本来可以不发生。

这份清单该由谁来管，运维还是SEO

从记录本身的性质看它是资产归属，从出问题的后果看它常常先在SEO这边爆出来——权限交接不干净、后台数据看不到、验证莫名其妙掉了。比较务实的分工是运维守着改动权限，SEO或者具体业务方负责说清每条记录对应哪个服务哪个账号。谁来记不重要，重要的是有人认领；这一轮130个大站的数据说明，没人认领的结果就是平均攒到14条还在往上加。

权威参考资料