SPF记录只有一行，展开要查几次是别人定的

摘要：把95个DTC与电商品牌的发信配置整个查了一遍。93个有SPF记录，看上去很健康；可把每条记录完整展开之后，7个品牌的DNS查询次数已经超过规范给的10次上限，另有6个正好卡在10。最离谱的一个记录只有122字节、只写了4个include，展开出来要查14次；而另一个记录长达1890字节的品牌，只要查7次。记录是你写的，展开之后要花多少次查询，是被你引用的那几家决定的，而他们改的时候不会通知你。

先把这件事的机制说清楚，因为它跟直觉相反。

SPF是一条写在域名下的文本记录，用来声明哪些服务器可以用你的域名发信。收件方拿到一封信，会去查这条记录，然后按里面的规则判断这封信的来路对不对。规则里最常用的一个词叫include，意思是“除了我列的这些，某某家授权的服务器也算”。

问题就出在这个词上。你写下一个include，收件方就得再去查一次那家的记录；而那家的记录里可能又写着好几个include，于是还得接着查下去。规范给这个过程定了一个硬上限：整条链上因为这类机制产生的查询，加起来不能超过10次。超了，收件方直接判定这条记录有永久错误，也就是当你没配。

一行SPF记录，展开之后为什么要查十四次？

先看那个14次的样本，一个做橄榄油的DTC品牌。它的记录长这样：

量一件事之前先想清楚对照物是什么，给那条建议配一个注定无效的对照组讲的是判断证据成不成立的基本功。

v=spf1 ip4:66.96.128.0/18 include:_spf.google.com include:websitewelcome.com include:mail.stay.ai include:mailgun.org ?all

122个字节，一个IP段，四个include。从写的人的角度看，这是一条非常克制的记录——只授权了四家：办公邮箱、主机商、一个订阅工具、一个发信服务。

先说清楚这次量了什么

样本是95个以北美DTC品牌为主的域名，覆盖服饰、床品、家居、户外、宠物食品、个护、3C配件、厨具几个品类，另外放了几个平台型站点做对照。对每个域名查了顶点域的文本记录、域名策略记录、收信服务器记录、几个常见的签名选择器，以及两项传输安全相关的记录。

横向普查的样本口径要先定死，按页面模板抽样做审计那篇讲清楚了口径不同会让结论差多远。

所有查询都走公开的域名解析接口，没有任何内部数据，你拿着同一份域名清单可以完全复现。唯一需要注意的是查询方式——后面会专门讲，用错方式会得到一个完全相反的结论。

展开计数的口径是：include、redirect、a、mx、exists、ptr各计一次，同一个目标在一条链上只展开一次。这个口径比规范略宽松一点点，所以文中给出的次数是下限；真实的判定结果只会更差，不会更好。

把这四家展开来看

授权、签名、策略这三样各自该怎么配，邮件投递率怎么从六成拉到九成七那篇按六个维度写过一份完整的落地顺序，跟本文正好互补。

主机商那一条最夸张。它自己的记录里又写了三个include，其中一个指向一家邮件过滤服务，那家的记录里再写两个，一层套一层，六次查询就这么出去了。写记录的人只敲了一个域名，实际请下来的是一整棵树。

这棵树上没有一个节点是他能改的

更关键的是所有权。这四家里，只有第一个和第三个的记录短到不会再变；另外两家的记录随时可能因为他们自己扩容、换机房、并购、加一个新的发信区域而变长。而每变长一次，这个品牌的查询次数就跟着涨一次。

凡是数据由别人生成、你只能读取的场景，都得先给尺子做校准，第三方工具的数据到底准不准给了一套六步校准法。

他既不会被通知，也没有任何位置可以看到这个数字。域名注册商的面板上不会显示，邮件服务商的后台不会显示，DNS托管商的界面上更不会。这个数只能自己去算，而绝大多数人从来没算过。

同样四个工具，另一个品牌只花了三次

为了说明这不是“工具装多了”的问题，把另一个品牌拿来对照。某旅行箱品牌同样接了办公邮箱、发信平台、客服系统三家，记录里写了两个引用，展开之后只要3次。

同一套工具在不同团队手里效果差很远，七种高回报自动化流的搭法与避坑记录了同一个平台上做得好和做得糟的两种配置。

差别在于它引用的是那家发信平台下面的具体子记录，而不是主域名。同样一家服务商，引用主域名要花5次，引用它下面的三条子记录只花3次。这个差别在服务商的接入文档里通常不会写，文档里给的永远是最省事的那一行。

把这两个品牌并排看，能得出一条很实用的判断：你的查询预算花在哪儿，不取决于你接了几个工具，取决于你抄了哪一份文档。

十次这个上限到底是怎么算的？

规范里对这件事写得非常明确。SPF规范第4.6.4节的原文是：实现必须把会触发DNS查询的那些词的总数限制在10个以内，以免给DNS带来不合理的负载。

规范和算法里的历史包袱都值得知道来历，从关键词匹配到意图理解的演变史是另一条同样需要读原文的线。

哪些词会计入

规范里哪些写法有效、哪些只是看着有效，是个反复出现的问题，某类规则能不能禁掉追踪参数是另一个典型的例子。

这张表里藏着这件事的全部解法：写IP不花钱，写域名才花钱。一条记录哪怕写满一千多个字节的IP段，查询次数也是零。

还有两个更容易被忽略的上限

除了总数10次，规范还写了两条细则。一条是mx机制展开时，每条收信服务器记录再去查地址，最多不能超过10个；另一条是所谓的“空查询”——查回来什么都没有或者域名根本不存在的那种——建议限制在两次以内，超了同样判永久错误。

各种协议里的隐藏上限比想象中多，抓取体积上限实测全拆解量过另一条几乎没人注意、但一旦触发就静默生效的界限。

第二条在实务里踩得最多。你写进去的某个服务商已经不用了，域名早就注销，这一条就成了一次空查询。攒够两次，整条记录报废，而它平时不报错，只在你被拒信的时候才显出来。

为什么是十，不是二十

这个数字定在10，是二十多年前的一个工程折中。当时的考量是：一封信到达时收件方要在几百毫秒内完成判定，每一次查询都可能跨越半个地球，10次已经是能接受的上限；再往上，恶意构造的记录就能把收件方的解析器变成攻击别人的工具。

工程折中定下来的数字往往几十年不变，召回到重排的四阶段拆解里也有一批这样的历史遗留参数。

这个理由今天依然成立，所以这个数字不太可能被放宽。换句话说，随着邮件工具链越来越长，这条上限只会越来越挤，不会越来越松。2005年一个域名接两三个发信渠道很正常，今天一个中等规模的DTC品牌接六七个是常态，而预算还是那10次。

另外还有一条容易忽略的长度限制

除了查询次数，记录本身还有一条物理限制：单个字符串片段最多255个字节。超过这个长度，就必须拆成多个片段，由解析方拼回去。

长度超标而不报错这件事在别的协议层也会发生，老用户打不开的那个页面工具全都返回二百是同一类静默失败。

样本里最长的那条记录有1890个字节，也就是被拆成了八个片段。这条限制本身不难满足，麻烦的是有些管理面板不支持自动拆分，粘贴超长内容时会静默截断，而截断之后的记录语法上仍然合法。这类事故的表现是“改完之后一部分渠道突然发不出去了”，因为被截掉的正好是末尾那几个引用。

判断的办法很简单：改完之后重新查一遍，把查回来的内容跟你粘贴的内容逐字符比一遍。不比对就等于没改。

谁在替你把这条记录撑长？

把95个品牌的记录全部展开，统计每一个被引用的目标各自要花多少次，能排出一份很有用的对照表。

上游越多，隐性成本越高，装太多应用拖慢店铺还烧钱算过另一条线上的同类账。

常见发信服务的真实成本

工具栈的隐性成本要定期盘，十二个站样本里的四维冗余与八步瘦身给了一份可以直接照着走的年度审计流程。

差距是五倍到七倍。同样是往记录里加一行，加办公邮箱那两家只花1次，加那家发信平台要花5次，加那家主机商要花7次。而这个成本在你敲下那一行的时候完全不可见——两行字看起来一模一样。

一个什么都不授权却照样收费的例子

样本里有一条特别有意思。某建站平台提供的发信域，它的记录内容是这样的：

照着文档抄配置最容易抄到过时的版本，逐字段填法与部署验证那篇强调的正是抄完之后必须自己验一遍。

v=spf1 ~all

翻译过来是：我不授权任何服务器，剩下的都算可疑。也就是说，把它写进你的记录里，一台服务器都不会被放行。

但它照样吃掉你一次查询。这一行是纯亏的：不带来任何授权，只消耗预算。样本里有品牌把它写在记录里，多半是照着某份配置文档抄的，而那份文档写的时候这个域名下面可能是有内容的。

还有一种成本藏在宏里

某客户关系平台的记录用了一种叫宏的写法，大意是“拿这封信的来源地址，拼成一个域名去查一下，查得到就算授权”。这种写法的好处是授权范围可以动态变化，坏处是它同样计一次查询，而且每一封信都要真的去查一次。

动态生成的东西在性能账上永远比静态的贵，内联编码与性能权衡算过这笔账在前端场景下的具体量级。

对收件方来说，这类记录的解析开销比普通的include高得多；对你来说，它在预算表上跟别的没有区别，一样占一格。用了这类服务的域名，链条上的其他部分就更要精打细算。

贵的那几家有个共同特征

把成本高的目标挑出来看，它们的记录里都有同一种结构：按区域或者按用途拆成了多条子记录，然后用一条主记录把它们串起来。比如某发信平台，主记录里写着三条子记录，分别对应两个通用池和一个欧洲池。

按子域拆分资源是常见的架构选择，子域名还是子目录的六维实战拆过这种拆分在另一条线上的代价。

这个设计从服务商的角度看完全合理：区域扩容时只改对应的那一条，不影响别的。代价是每多拆一条，所有引用主记录的客户就多花一次查询——而这个代价完全由客户承担，服务商这边零成本。

理解了这个结构，优化路径就清楚了：如果你只用某一个区域的服务，就只引用那一条子记录，别引用主记录。样本里那个只花3次的旅行箱品牌，用的正是这个办法。风险是服务商新增子记录时你不会自动获得，所以要配一条季度复查。

把95个域名引用过的目标排个榜

统计所有域名引用过的目标，出现频次最高的十几个基本覆盖了这个赛道的发信技术栈：办公邮箱两家占绝对多数，其次是几家发信平台、一家营销自动化平台、一家客服系统、一家评价工具、一家订阅管理应用。

一个DTC品牌的标配工具栈到底有多长，十二款覆盖选品到客服的真实测评清单列得比较全，可以对着数一遍自己接了几个。

把频次和成本放在一起看，会发现一个不太妙的组合：出现频次最高的那几家里，恰好有两家的成本在5次以上。也就是说这个赛道的默认技术栈，光是标配就要吃掉一半以上的预算，剩下的空间留给那些每个品牌各不相同的长尾工具。

这解释了为什么越线的七个品牌没有共同的行业特征——他们不是装得比别人多，是在标配已经吃掉六七次之后，又各自加了两三个长尾工具。

超过上限之后会发生什么？

这是最容易被误解的一环。很多人以为超限只是“效率低一点”，实际上后果是断崖式的。

判错和降权的恢复路径完全不同，垃圾更新到底打了什么那篇的恢复步骤同样强调先确认判定结果再动手。

一条记录是怎么慢慢变长的

把时间线还原一遍，会发现没有任何一步是错的。

一步步走偏这件事只能靠固定检查点拦住，六站四降权的反垃圾边界与三处人工节点复盘过同样的累积过程。

第一年开店，接办公邮箱，记录里一个引用，查询次数1次。第二年上营销自动化，加一个引用，变成2次。第三年上客服系统，那家的记录里套了两层，一下子变成8次。第四年财务上了一个开票工具，9次。第五年为了做一次活动接了个抽奖平台，10次。第六年营销团队换了发信平台，新平台的记录比老的贵三次，11次——越线了。

整个过程里，每一次都是一个合理的业务决策，每一次改动都只加了一行，每一次改完邮件都能正常发出去。越线发生在第六年的某个下午，而那天所有的测试都会通过，因为测试用的是主渠道，主渠道恰好在链条的前半段。

这就是这类问题最麻烦的地方：它不是被某一次错误操作引入的，是被六年里六次正确操作累加出来的。没有任何一次代码评审、任何一次上线检查能拦住它，因为每一次的增量都完全合理。能拦住它的只有一个东西——一个持续存在、每次改动都会重算的总数。

结果不是降级，是判错

规范写得很直接：超过限制，实现必须返回永久错误。这个结果跟“没有SPF记录”是两回事，也跟“不通过”是两回事——它是一个明确的“这条记录有问题”的信号。

判定结果错一格，后面全盘皆错，人机验证屏被当正文索引那次事故的连锁反应跟这里的机制完全同构。

收件方拿到这个结果会怎么处理，各家不完全一样，但共同点是你的SPF不再提供任何正面价值。原本能靠它通过的信，现在得完全依赖另一套签名机制；如果那套也没配好，这封信就只剩下内容特征可以判断了。

它还会顺带弄坏你的对齐关系

更麻烦的是连锁反应。域名策略的判定要求信封发件人和信头发件人跟你的域名“对齐”，而这个判定依赖SPF或者签名至少有一个通过。SPF一旦判永久错误，这条腿就废了。

同一封信要同时满足好几套要求，一键退订必须写两层少一层就限流整个域名是另一条差一点就整域受影响的规则。

假如你的域名策略设成了拒绝，而签名那条腿也恰好在某个发信渠道上没配，结果就是那个渠道发出去的信被收件方直接拒收——不是进垃圾箱，是根本不投递。这类事故的典型表现是“别的邮件都正常，就某一类通知发不出去”。

为什么它能潜伏很久

因为超限的信不会立刻全军覆没。签名那条腿正常的渠道照样通过，只有那些依赖SPF的渠道会出问题；而依赖SPF的往往是些不起眼的系统发信——发票、密码重置、客服回复。这些邮件没人盯着送达率，用户收不到通常也不会投诉，只会默默重新操作一遍。

静默失败只能靠主动监控发现，搭一套监控告警体系在掉量前抓住事故给了分层告警的具体设计。

被退回来的那封信长什么样

真出事的时候，你能拿到的第一手证据是一封退信。它的正文里通常会有一行状态码和一句英文说明，说明里往往直接写着永久错误，或者写着策略判定不通过。

从外往里逐层排查是通用方法，从解析、线路到分发的网络层排障那篇的分层顺序可以直接搬到邮件链路上。

这一行是排查的起点，但它有个陷阱：说明里提到的域名，可能是你的域名，也可能是某个中间转发方的域名。用了转发、用了群发平台、用了带自动回复的客服系统时，链路上不止一个域名参与判定，退信里指的未必是你。

看退信的正确顺序是先找信封发件人，再找信头发件人，最后才看判定结果针对的是哪一个。这三个经常不是同一个域名，而绝大多数排查的时间都浪费在没意识到这一点上。

为什么不会有人主动告诉你

值得把这件事的机制说透：收件方判定失败之后，它的义务是决定要不要收这封信，不是通知你去修记录。整条链路上没有任何一方有动机、有渠道、也有责任来告诉你“你的记录写错了”。

没有回执的自动化迟早会跑偏，内容自动化按周排期就是在逼自己发水文讲的正是缺少反馈信号带来的后果。

唯一接近这个功能的东西是域名策略的聚合报告——它会告诉你有多少信没通过判定。但它有两个先决条件：你得配了报告地址，而且得有人真的去读。后面会讲到，这两个条件的实际满足率有多低。

95个品牌里，有几个已经越线了？

把93条有记录的域名按展开后的查询次数排开，分布是这样的：

多源交叉是这类普查的基本功，三角验证的九十天框架给了一套把三种数据源拼在一起的做法。

中位数是7次。7.5%已经越线，另有28.0%处在只剩两三格余量的位置。也就是说超过三分之一的品牌，在下一次“我们要加一个新的发信工具”的时候会直接撞墙，而且撞了不会响。

越线的那七个都在做什么生意

分别是橄榄油、可持续服饰、休闲男装、家具、体香剂、气泡饮料、相框定制。它们没有共同的行业特征，也没有共同的规模特征。共同点只有一个：都是那种会同时用五六个营销与运营工具的品牌。

工具接得多往往是私域做得深的副产品，邮件加社群加复购飞轮的四段路线说明了这些工具各自在哪个阶段引入。

看它们的记录也能验证这一点。有的写了9个include，有的只写了4个，但被引用的对象里都至少有一个是“成本很高”的那种。数量不是主因，选谁才是。

这个比例在别的样本里是什么水平

7.5%越线、28.0%没有余量，这两个数字放在行业里算好还是差？没有公开的权威基准可以对，但可以从结构上推一推。

越线的概率主要由两件事决定：接了几个发信渠道，以及那些渠道各自有多贵。DTC品牌的渠道数普遍在四到七个之间，比传统零售多，比软件公司少。而软件公司通常还要加上客户关系系统、工单系统、产品内通知、账单系统，渠道数轻松上十，越线比例只会更高。

反过来，那些只用一个办公邮箱加一个营销工具的小品牌，展开次数常年在两三次，永远不会碰到这条线。所以这件事有个很清晰的规模门槛：当你的发信渠道超过四个，就该开始数这个数；超过六个，就该把它做成每周自动跑的检查。

这批样本里那29个还在1到4次的域名，绝大多数正是渠道少的那一类，而不是配置做得特别好的那一类。宽裕不等于用心，只等于还没长大。

正好卡在10次的那六个更值得担心

10次是允许的上限，所以这六个技术上完全合规。但它们的余量是零：任何一家上游多加一行，或者自己再接一个新工具，第二天就越线。

把发信这类动作从主流程里摘出去是另一种解法，下单接口里那行发邮件的代码量过它对响应时间的实际影响。

这六个里有一个特别典型：它的记录里一个include都没有，只写了一条转发指令指向某家邮件安全服务的一个随机字符串子域，39个字节。整条记录短得像个笔误，展开出来正好10次，全部由那家服务商决定。这个品牌对自己发信授权的控制权，实际上是零。

这七个各自还能省出多少

逐个算一遍它们的自救空间，结论比想象中乐观。

按性价比排序再动手，能省掉大量无效工作，十一个按性价比排序的速赢清单给了一个可以复用的排序方法。

光靠“把最贵的那一条换成它下面的具体子记录”这一个动作，就有五个能回到合规范围内。剩下两个需要再砍掉一个已经不用的工具，而这类工具在每个品牌的记录里几乎都能找到至少一个。

动手改之前先留一份回滚

改这条记录有个物理特性要提前知道：它有缓存时间，改完之后旧值可能还会在世界各地存活几小时甚至一天。这意味着改错了不能立刻撤回，撤回也要等同样长的时间。

回滚点这件事必须提前演练，备份了就安全吗恢复演练才是真底气说明了没演练过的回滚方案基本等于没有。

所以顺序应该是：先把当前值原样存一份到文档里，注明日期和改动人；把缓存时间临时调短到五分钟，等旧缓存过期；再改内容；观察一两个小时确认各渠道正常；最后把缓存时间调回去。

这一套走下来大概半天，比直接改多花三四个小时，但它把“改错了要等一天才能恢复”变成了“改错了五分钟就能退回去”。对一个每天发几万封交易邮件的站来说，这三四个小时的投入非常划算。

怎么知道哪个工具已经不用了

这一步没有捷径，只能问人。但有个能缩小范围的办法：把记录里的每一个引用目标拿去搜一下服务商名字，然后对着公司这两年的采购记录和后台账号列表比一遍。

留改并删这套决策结构在内容侧已经很成熟，上千篇旧内容的留改并删转决策的表结构可以直接搬来盘工具。

凡是没人记得账号密码的，基本可以确定已经停用；凡是账号还在但过去一年没登录过的，值得单独确认一次。实务上一条记录里躺着两三个僵尸引用是常态，因为停用工具的时候没有人会想到回来改这条记录。

记录写得短，是不是就一定省查询？

这是这次数据里最反直觉的一条。

长度和成本的关系在传输层同样不直观，每个请求都把同一份数据重发一遍量过压缩机制下的真实开销。

兜底规则那一栏也值得单独看

把93条记录末尾的兜底规则统计一下，分布是这样的：

规则的实际效力和它写没写常常是两回事，弹窗会被降权吗拆过另一条被普遍误解的判定规则。

近七成用软失败，这个比例本身不奇怪——几乎所有接入文档给的示例都是软失败，因为它最不容易出事。问题在于绝大多数品牌从配上那天起就再也没改过，软失败从过渡状态变成了永久状态。

那5个什么都没写的更值得说一句。没有兜底规则时，判定结果是中立，收件方拿到一个既不通过也不失败的结论，等于这条记录白配。这5个域名在各种检测工具里多半都是绿灯，因为工具只检查记录存不存在、语法对不对，不检查它有没有实际效果。

两个极端摆在一起

体积大小和实际影响之间常常没有直觉上的关系，网页体积越大排名越差吗用官方口径拆过另一个同样反直觉的例子。

第一行那个1890字节的记录，把大量IP段直接写了进去，只留5个include，展开只要7次。记录长度和查询成本几乎不相关，因为成本不由字数决定，由你引用了谁决定。

用长度换次数是一条真实可行的路

把某个上游的IP段抄进自己的记录，就能省掉那一次查询和它下面的所有查询。代价是那家换IP的时候你要跟着改，改晚了就发不出信。

写死之后必须配复查，而复查最好交给定时任务，用定时任务把独立站运维自动化有现成的调度与告警写法。

这笔账怎么算，取决于那家改IP的频率。大型云邮箱几年不动一次，值得抄；小型SaaS工具随时可能换，抄了就是给自己埋雷。实务上的分界线是：对方有没有公开承诺过IP段的稳定性，以及有没有变更通知渠道。

样本里有人已经这么做了

某旅行箱品牌的记录里，没有直接引用那家发信平台的主域名，而是分别引用了它下面的三条子记录。这三条子记录正是主域名展开之后的内容——相当于有人手工把那棵树剪掉了一层，把5次压成了3次。

手工优化最怕的是没人回来复查，那套自动化从第二周就开始走形复盘过缺少护栏的自动化是怎么慢慢坏掉的。

这是个聪明的做法，但也有风险：那家如果新增第四条子记录，这个品牌不会自动获得。所以这类手工优化必须配一条复查规则，否则省下来的两次查询，迟早会以“某个区域发出的信全部不通过”的形式还回去。

四种记录形态的对照

把这批样本里的记录按形态归一归，大致是四类，各自的风险点完全不同。

域名层的架构选择会长期锁定你的很多余地，国际站的域名结构怎么选把几种形态的长期代价摆在了一起。

样本里第一类最多，第三类只有个位数，第四类有三个。第四类最值得警惕：它把整条记录的内容交给了一家第三方，那家改成什么样你都得接受，而且看不出来。用邮件安全网关服务的品牌容易落到这一类，因为服务商的接入指引就是这么写的。

该往哪一类靠

对绝大多数DTC品牌，混合型是最合适的落点：把两三家最稳定的上游用IP段写死，剩下的用引用，总数控制在7次以内留出余量。

域名相关的决策最好一次做对，独立站域名怎么选的八步决策路线给了一份可以照着走的判断顺序。

判断某家该不该写死IP，看三条：对方有没有公开的IP段清单页、有没有变更通知渠道、过去两年改过几次。三条都满足就写死，缺一条就保留引用。这个判断做一次，之后每年复核一次即可。

那条没写sp的DMARC，把子域交给了谁？

发信身份这条线上，还有一个更彻底的“上游代填”，藏在域名策略记录的一个可选标签里。

解析层的每一次改动都要留回滚点，换主机搬家的数据库替换与切换流程给了一份可以照做的执行清单。

不写就随父域

DMARC规范的标签定义一节规定：如果没有显式写子域策略这个标签，子域就沿用主域的策略。听上去很合理，直到你意识到营销邮件通常不是从主域发出去的。

父域和子域的边界在浏览器那边也有一套独立规则，后台一个域前端一个域浏览器认不认它们是同一个站讲的是另一半。

95个域名里93个有策略记录，其中79个没有写子域策略标签，占84.9%。这79个品牌的每一个子域——包括那些用来发营销邮件、发交易通知、发客服回复的子域——都在默默沿用主域的设置。

沿用本身不是问题，不知道自己在沿用才是

如果主域策略是拒绝，子域跟着拒绝，那是好事；问题在于反过来的情况也一样自动发生。样本里主域策略为“不做处理”的有20个，占21.5%，这20个品牌的所有子域也一并处于不做处理的状态，包括那些每天往几十万人收件箱里发信的子域。

子域上的一个动作影响到整个主域，这类作用域事故非常常见，一张自家子域上的图片把登录态删得一干二净就是一例。

更隐蔽的是新建子域。今天营销团队为了一个活动开了一个新的发信子域，它出生那一刻就自动继承了主域的策略，没有任何人做过这个决定，也没有任何流程会记录这件事。

先把在用的子域列出来

要处理这件事，第一步不是改记录，是搞清楚到底有几个子域在发信。这一步比想象中难，因为没有任何一个地方存着这份名单。

批量提取和归并这类清单有现成工具，六种格式解析与批量提取那篇的思路可以改造成子域盘点脚本。

可用的线索有四条：一是聚合报告里出现过的发件域，这是最准的一条，前提是你确实在收报告；二是各个营销与运营工具后台里配置的发信域；三是解析记录里那些带着签名选择器的子域，它们的存在本身就说明有人在那儿配过发信；四是问一遍市场、客服、财务三个部门最近一年上过什么工具。

四条线索交叉之后通常会比任何人预估的多出两三个，而多出来的那几个往往正是风险最高的——因为没人记得它们，也就没人维护它们。

签名选择器能反推出接了哪些服务

这次对95个域名探了八个常见的签名选择器名字，命中情况可以直接用来判断它接了哪几类服务：两个通用选择器的命中率分别是68.4%和67.4%，另外几个专属选择器的命中率在7%到28%之间。

把一堆主机名归并到根域名是这类盘点的第一步，域名提取器怎么用讲清楚了去重口径该怎么定。

注意这只是八个常见名字的命中数，实际数量只会更多，因为很多服务商用的是随机字符串做选择器名，猜不到。但即便如此，超过七成的域名探到了两个以上，说明多渠道发信在这个赛道已经是默认状态，而多渠道正是所有这些问题的根源。

为什么四个显式写了sp的品牌，全都写松了？

93个里有14个显式写了子域策略标签。把它们跟主域策略比一比，结果很有意思：

规则写松容易写紧难，这在营销规则里同样成立，客户细分的动态规则与分组区别解释了规则叠加时的优先级。

四个不一致的，全部是把子域放得比主域松：两个从拒绝降到不做处理，一个从拒绝降到隔离，一个从隔离降到不做处理。没有一个品牌把子域收得比主域更严。

三档策略的实际分布

93个有策略记录的域名里，主域策略的取值分布是这样的：

一份准则里真正会变成分数的往往只有一部分，九十七条准则只有七十条会变成分数量过这个落差。

四成已经收到最严的那一档，这个成绩在跨行业比较里算好的——很多传统行业这个比例还在个位数。DTC品牌普遍做得比较快，原因很直接：主流邮箱这两年把这项列进了批量发件人的硬门槛，做不到会被限流，而限流直接砍营收。

但这四成里藏着一个隐患。主域收到拒绝这一档之后，子域的默认状态也变成拒绝——这本来是好事，前提是所有在发信的子域都已经配好了授权和签名。如果有一个子域没配全，从主域收紧那一刻起，它发出去的信就开始被拒收，而没有人会把这两件事联系起来。

这个方向是有原因的

写这个标签的动作，往往发生在某次事故之后：主域收紧到拒绝，结果某个子域发出的信被大面积拒收，紧急处理的办法就是给子域单独开个口子。于是这个标签的实际用途不是“精细化管理”，是“给主域收紧留个退路”。

临时口子往往是组织问题不是技术问题，甲方拒绝建议八成是身份冲突给了一套把技术方案讲进决策层的写法。

这本身不算错，是务实的过渡手段。但它有个必须配套的动作：那个口子要有关闭的日期。实务里见过最久的一个口子开了三年，开它的人早就离职，而那个子域后来被当成了群发通道。

正确的用法长什么样

如果你确实需要用这个标签，建议按这个顺序做：先给每一个在用的发信子域单独写一条自己的策略记录，写完之后主域的标签就只对“没人管的子域”生效，这时候把它设成最严的那一档，反而是安全的。

先补齐再收紧这个顺序在域名整合里同样适用，多个域名要不要合并成一个站给了完整的执行次序与回滚点。

换句话说，这个标签的最佳取值是拒绝，前提是所有该发信的子域都已经有了自己的记录。大多数品牌的顺序反了：先动主域和这个标签，再回头补子域，中间那段时间就是事故窗口。

回执配了，可有人看吗？

域名策略记录里有一个专门用来接收聚合报告的地址。收件方每天会把统计结果打包发过来，告诉你有多少信通过、多少没通过、都是从哪些IP发出去的。

报告有没有人看，取决于有没有人对它负责，数据分析师与技术对账的七个动作点给了一套责任划分的做法。

覆盖率很高，但这不说明什么

93个有策略记录的域名里，85个配了聚合报告地址，占91.4%；配了取证报告地址的40个，占43.0%。这个覆盖率比前面所有指标都好看，原因也很简单：几乎所有生成这条记录的在线工具都会默认帮你填上这一行。

覆盖率这类指标最容易被工具默认值抬高，审计工具号称的准确率是自己划的及格线拆过同一种统计幻觉。

问题在下一步。聚合报告是一份压缩过的机器格式文件，一天几封到几十封，靠人眼是读不了的。配了地址不等于有人在看，甚至不等于那个邮箱还有人在用。样本里有好几个域名的报告地址指向的是通用别名，这类地址在多数公司里是没有人订阅的。

取证报告为什么覆盖率低一半

聚合报告的配置率是91.4%，取证报告只有43.0%，差了一倍多。这个差距不是疏忽，是有意为之。

上报量一大就没人看，这是所有回执类机制的通病，报表里的机器流量怎么揪出来再拦掉给了几种可复用的降噪思路。

取证报告的内容包含单封邮件的详细信息，其中可能带有收件人地址和邮件头。很多收件方出于隐私考虑根本不发这类报告，发的那些也会做大量删减。更实际的问题是它的量：一个被冒充的域名可能一天收到几万封取证报告，直接把接收邮箱撑爆。

所以这项的正确用法不是常开，而是在排查具体事故时临时打开，查完关掉。把它长期开着并且指向一个没人管的邮箱，是这批样本里能看到的第二常见配置——第一常见是聚合报告指向一个通用别名。

一个可以自查的动作

去那个报告地址的邮箱里搜一下最近三十天的邮件数量。如果是零，说明要么没人在往那儿发，要么这个邮箱早就被规则归档了；如果有几十封而且从来没被打开过，那这条配置的实际价值也是零。

点了按钮不等于对方真的复核了，验证修复到底在验证什么说明了这类操作的实际语义跟界面上写的常常不一样。

回执这件事的判据不是配没配，是最近一次有人因为报告里的内容做出过决定是什么时候。答不上来，就等于没有。

比例标签也是同类问题

策略记录里还有一个按百分比生效的标签。样本里显式写了这个标签的40个域名中，35个写的是100，另外5个分别写了5、5、75、75、50。那两个写5的，意味着它的策略实际上只对二十分之一的邮件生效——记录上写着拒绝，实际拒绝的只有5%。

按比例放量是灰度上线的标准做法，三十个实验方案从按钮到结账里的放量节奏可以借来设计收紧计划。

这个标签同样是过渡工具，用来在收紧策略时逐步放量。而跟前面那个子域标签一样，它的问题不是被用错，是被用完之后没人回来把它改掉。

报告里真正有用的三个字段

假如你决定认真读一次聚合报告，只看三样就够了。

报表里字段一多就没人看了，核心指标解析的四个错误讲的正是怎么从一堆字段里挑出真正驱动决策的那几个。

第一样是发信IP。报告会把统计按源IP分组，你只要看有没有自己不认识的IP在用你的域名发信。认不出来的IP如果通过了判定，说明它在你的授权名单里，那你该去查是哪个引用把它带进来的；如果没通过，那多半是冒充。

第二样是判定结果的分布。同一个IP如果有一部分通过一部分不通过，通常意味着这个渠道的配置只做了一半——比如授权配了签名没配，或者签名配了但对齐关系不对。

第三样是发件域。报告里会列出每一封信声称的发件域，把它跟你自己列的子域清单对一遍，能直接发现有没有你不知道的子域在发信。这一项是发现僵尸子域最有效的手段，比问人靠谱得多。

不用自己解析那些文件

聚合报告是压缩过的结构化文件，靠人眼读很痛苦。市面上有一批专门做这件事的服务，把报告解析成图表；也可以自己写十几行脚本解压、解析、按发件域汇总。

把解析、汇总、发摘要这几步串成流水线并不难，四个场景的工作流闭环给了可以直接改造的节点结构。

但无论用哪种方式，关键的一步是让它每周产生一封人能看懂的摘要邮件，发到一个具体的人手里，而不是一个部门别名。这一条比工具选型重要得多——所有失败的监控最后都失败在“这封邮件没有具体的收件人”上。

同一个域名问九次，为什么答案不一样？

这一节讲的是这次量的过程本身，因为量具在这件事上出的问题，比结论还值得记一笔。

同一个地址对不同来访者给出不同内容，这件事要先量出来，渲染对比器怎么用就是专门干这个的。

第一次量出来的结果是错的

最开始用本机的解析器查了一遍，95个域名里只有35个查到SPF记录，其余60个显示“没有这条记录”。这个结果显然不对——里面有好几个是全球知名的大品牌，不可能不配。

换台设备结果就变，这类量具问题在排名监测里更常见，排名监测为什么老对不上列了六个具体原因。

换一家公共解析服务再查，变成55个有记录。再换一家，又是另一个数字。同一批域名、同一天、同一个查询类型，三把尺子给出三个答案。

原因是记录集被截断了

顶点域名下面的文本记录通常不止一条：各种平台的所有权验证串、办公软件的验证码、若干个服务商的标识，加起来常常有二三十条。而SPF那一条往往是里面最长的。

解析器在某个字节位置之后就不再往下看，这类边界问题很隐蔽，乱码的分界不在一千零二十四字节量过另一个例子。

当这个记录集大到一定程度，不同的解析路径会返回不同的子集。而SPF那条因为最长，最容易成为被丢掉的那一条。更让人不安的是，返回的响应里并没有任何“内容不完整”的标志，看上去就是一份正常的答案。

连问五次，五次不一样

拿一个眼镜品牌的域名对着同一家解析服务连问五次，返回的记录条数分别是16、16、15、17、16条，而SPF那一条只在第三次出现。

同一件事多问几次再取并集，是应对随机性的通用手段，排名追踪要不要每天扫算过抽样频率与成本的平衡点。

这不是缓存问题，也不是网络问题，是记录集在返回时被裁剪，而裁剪掉哪几条带有随机性。如果你只查一次，有八成的概率会得出“这个品牌没配SPF”的结论。

最后用的办法

换成四家解析服务、其中三家各问三次，一共九次查询，取所有结果的并集。这样一来，93个域名查到了记录，只剩2个确实没有。

交叉验证这件事在识别爬虫真伪时也一样必要，一百二十种标识分类与真假验证给了一套双向核对的做法。

把九次查询里“能看到SPF”的次数统计一下，分布很说明问题：

九次全命中的只有两个域名。换句话说，绝大多数品牌的这条记录，在任何一次单独的查询里都有概率查不到。四家解析服务在这批域名上返回的记录条数合计分别是1899、1111、493和154条，最少的那家只有最多那家的8%。

四家解析服务的差距有多大

把九次查询按来源拆开，各家返回的记录条数合计差得很离谱：

甲这一家几乎每次都返回完整集合，乙只有六成，丙只有四分之一。如果这次只用丙那一家，得出的结论会是“超过一半的DTC品牌连基础的发信授权都没配”——一个足以写成标题、但完全错误的结论。

丁那一家的154条不是它不行，是查询频率超过了免费额度被限流，返回了大量空结果。这一条同样值得记：做批量查询时，被限流的响应和“确实没有”的响应在数据里长得一模一样，脚本必须把两者分开记录，否则限流会直接伪装成结论。这次的做法是把状态码不为成功的响应全部丢弃、不写入缓存，只统计真正拿到的那些。

这件事对你的意义

如果你用某个在线检测工具查过自己的记录，结果说“未检测到SPF”，先别急着重新配置。换一家工具再查一次，或者换一个网络环境再查一次。贸然重新添加一条，结果就是同一个域名下出现两条SPF记录——而规范规定这种情况直接判永久错误，比原来更糟。

不同平台对同一件事的判定口径常常不同，三个平台后台的告警怎么分级诊断整理了各家结论打架时该信谁。

这次的样本里就抓到一个：某厨具品牌的域名下有多条SPF记录，来源多半正是某次“查不到就再加一条”的操作。

这类量具问题有个通用形态

把这次踩的坑抽象一层，形态是这样的：你的测量工具在没有报错的情况下返回了不完整的结果，而不完整的部分恰好是你最关心的那一条。

把判断交给工具之前有三个前提要满足，数据、方法与人工复核这三关说明了哪一关最容易被跳过。

它之所以危险，是因为缺失和“确实没有”在返回值上长得一模一样。工具不会说“我只拿到了一部分”，它只会给你一份看上去很完整的列表。而你的结论会直接建立在这份列表上，并且看起来完全合理。

防这类问题只有一个办法：用两把独立的尺子量同一件事，对不上的地方单独查。这次的做法是四家解析服务交叉，代价是查询量翻了九倍，收益是把“没配”从60个降到2个。如果只用一把尺子，这篇文章的结论会是“超过六成的DTC品牌没配发信授权”——一个完全错误、但听上去很有冲击力的结论。

为什么这次没用现成的检测网站

网上有一批做这类检测的在线服务，输入域名就能出报告，比自己写脚本省事得多。这次没用它们，原因有三个。

现成工具适合快速判断，不适合做横向普查，十款技术栈检测扩展实测对比也提到过同样的取舍。

第一是它们大多只查一次，而这批域名的记录集有概率被截断，单次查询的结论不可靠。第二是它们的展开口径不透明，有的只数第一层，有的会把重复目标算两次，横向比较时口径不一致。第三也是最关键的：它们不给原始数据，你只能看到结论，看不到那棵展开树，而这次真正有价值的发现全在树的形状里。

自己写脚本的成本其实不高，核心逻辑就是递归查询加计数，几十行就能跑。做横向普查时，宁可自己写一个粗糙但口径透明的工具，也不要用一个精致但口径不明的现成服务。这条经验不限于邮件，任何需要跨样本比较的场景都适用。

顺带说说另外两个更小的坑

一是有些解析服务会把长文本记录里的转义字符原样返回，如果你的脚本没做还原，拼出来的记录会多出几个反斜杠，导致后面的语法解析全错。

域名里的字符处理有一堆容易翻车的细节，网站上所有的字都是给用户读的只有域名要他自己打讲了另一批同类问题。

二是大小写。域名查询本身不区分大小写，但有些服务对混合大小写的查询会走不同的缓存分区，返回的记录集也可能不同。脚本里统一转成小写再查，能省掉一类查不出原因的偶发差异。

三十秒怎么查自己这条链有多长？

不需要工具，命令行就能做，但要按顺序来。

把一次性排查沉淀成固定流程，全站审计的十二类问题排查清单的组织方式值得借鉴。

第一步：把记录完整取出来

dig +short TXT example.com | grep spf1

如果这一步返回空，别下结论，换一个解析服务再查一次：

不想装命令行工具的话，接口测试工具怎么用也能完成同样的查询，而且能把多次结果并排放着看。

dig +short TXT example.com @8.8.8.8 | grep spf1
dig +short TXT example.com @1.1.1.1 | grep spf1

三次都空，才可以认为确实没有。三次里只要有一次拿到，就以拿到的那次为准。

第二步：手工数一遍

把记录里的include、redirect、a、mx、exists、ptr这几个词数一遍，得到第一层的数量。然后对每一个include的目标重复第一步，把它们各自的数量加上去，一层一层往下。

手工数完记得存下来做基线，十二个表格公式把数据活自动化里有把这类清单变成可自动更新表格的具体写法。

听起来麻烦，实际上大多数域名两层就到底了。真正要小心的是那些名字里带主机商、客服系统、资源系统字样的目标，它们往往还有第三层。

第三步：把结果放进三档里

分档判断比给一个精确分数实用得多，企业网站审计到底该查什么那份框架的分级方式可以直接复用。

顺手再看两样

一是记录末尾的兜底规则。样本里用软失败的65个，占69.9%；用硬失败的21个，占22.6%；还有5个压根没写兜底规则，2个写的是中立。没写兜底规则的那5个，相当于对所有不在名单上的服务器都不表态，等于没有防护效果。

顺手验证这类小动作最好做成固定清单，模拟身份测站与那条改不动的反向验证给了一份可以照抄的检查项。

二是有没有拼写错误。样本里抓到一条，某家具品牌的记录中间少了一个空格，两个引用粘成了一个不存在的域名：

include:sendgrid.netinclude:spf_c.oraclecloud.com

这一个空格，让两家服务商的授权同时失效，还额外制造了一次空查询。而这条记录已经这样存在了不知道多久，因为没有任何机制会告诉你它写错了。

把三步做成一张能贴出来的卡

这三步值得做成一张固定的检查卡，每次接新工具、每次换服务商、每个季度各跑一遍。卡上只写四行：

把检查嵌进流程比事后补救便宜得多，自动化为什么不能放到尾段做说明了关口该设在哪一步。

四行填完不到十分钟，而它能拦住的返工是以周计的。这张卡最大的价值不是发现问题，是让“接一个新工具”这件事从此有了一个必须经过的关口。

顺手做一次跨渠道对账

还有一个动作值得一并做：把所有在用的发信渠道列出来，逐个确认它们的授权、签名、对齐关系三样是不是都配齐了。

不同渠道的分工要先理清楚，自动化流与一次性群发的分工和协同把各类邮件的归属讲得比较清楚。

实务上最常见的缺口是签名配了但对齐关系不对——签名用的是服务商的域名，不是你的子域，这样签名本身有效，但在策略判定里不算数。这个缺口的表现跟授权超限一模一样，都是“通过率莫名其妙偏低”，而排查方向完全不同。

对账表做出来之后通常会发现，六七个渠道里有一两个是半配的状态。这一两个往往是当初赶活动匆忙上线的，上线时能发出去就没人再管了。

上游代填怎么才能变成可监控的东西？

前面说的所有问题都有同一个形状：值是你写的，展开之后的实际内容由别人决定，而变化没有回执。要治它，只能自己给自己造一个回执。

哪些活该交给工具、哪些不能，是这类监控设计的前置问题，自动化的边界在哪给了一条比较务实的分界线。

做一个每周跑一次的展开计数

脚本很简单：取记录、递归展开、数次数、跟上周比。只在数字变化时告警，不变就不出声。这样一年下来大概会响两三次，每次都对应着某家上游改了记录，而这正是你需要知道的事。

定时表达式不用背，定时表达式生成器怎么用可以直接生成每周一次这类规则并顺手校验一遍。

告警内容里要带上是哪一条子链变长了，否则收到通知的人还得自己再展开一遍。实务上把上周和本周的展开树一起附上，对比一眼就能看出多了哪一层。

把这个数写进采购清单

接入一个新的邮件工具之前，先查一下它的记录要花几次。这件事三十秒能做完，而它能避免的返工是几周。

采购前把长期成本算进去是通用纪律，产品差异化突围的微创新与人群细分里的评估结构同样适用于工具选型。

如果一家工具的记录要占五次以上，就该问对方两个问题：能不能给一份稳定的IP段清单，以及能不能提供一个更精简的引用目标。不少服务商其实两样都有，只是默认文档里写的是那个最省事的写法。

给子域一次性补齐记录

把所有在用的发信子域列出来，每个都单独写一条自己的策略记录，写完之后主域那个标签才能安全地收紧。这个动作是一次性的，做完之后新建子域的默认状态就从“随便”变成了“最严”，方向就对了。

补记录的同时顺手把获客链路的合规项一起过一遍，邮件列表从零养到能变现列了双重确认与留存证据的具体做法。

顺带把两个基础项也补上：一是加密传输策略，样本里只有3个域名配了，占3.2%；二是传输报告，只有6个配了，占6.3%。这两样的作用是让你的邮件在服务器之间传输时不被降级到明文，配置成本很低，覆盖率却低得离谱——又是一个典型的“需要自己动手就没人做”的格子。

把这件事交给谁

最后一个现实问题：这套东西该由谁负责。答案在多数团队里是空的，这也是它长期没人管的根本原因。

技术侧觉得这是营销的事，因为发信是营销在用；营销侧觉得这是技术的事，因为要改解析记录。结果这一格落在两个部门中间的缝里，直到某天大促的邮件发不出去，才会有人临时抓一下。

比较可行的分工是：解析记录的修改权在技术侧，但“我们现在有几个发信渠道”这份清单的维护责任在营销侧，两边共用一张表。技术侧每周跑一次展开计数，数字变了就通知营销侧确认是不是他们接了新东西；营销侧接新工具之前，先在表上加一行并把预期成本填上。

这个流程听起来重，实际每次只花几分钟，而且它有个附带好处：那张表本身就是一份完整的发信渠道清单，做合规审计、做工具续费评估、做事故排查的时候都用得上。一件事同时喂饱三个场景，才有可能被长期维护下去。

不要只盯着自己这一段

最后提醒一句范围。发信这件事的链条比多数人以为的长：域名解析、发信服务、签名、收件方策略、收件人所在的邮箱服务商，每一段都有自己的默认值和自己的上游。你能直接控制的只有中间很小一段，而失败的表现形式全都是同一句“对方没收到”。

链路最前端的收集环节同样影响后面的送达，邮件弹窗怎么设计才不招人烦讲了字段与时机对名单质量的影响。

所以排查的顺序应该是从最外层往里走：先确认对方那边有没有拒信记录，再看策略判定结果，再看签名，最后才看这条记录。反过来从记录查起，容易在一个没问题的地方花掉一整天。

顺带把两个能拿分的项也补上

这批样本里还有两项覆盖率低得反常的东西，值得一并处理。

可验证的出处正在变成新的信任货币，内容溯源与可验证出处讲了品牌标识之外另一条正在成形的信任线。

一是品牌标识记录，也就是让收件方在收件箱里显示你的品牌图标的那套机制。95个域名里有38个配了，占40.0%——这个比例反而不低，因为它有明确的商业收益，市场部愿意推。但它有个前置条件：主域策略必须至少是隔离那一档。所以那20个还停在不做处理的品牌，即使做了图标也不会显示，这笔钱等于白花。

二是收信服务器的分布，能反过来告诉你这个赛道在用什么。样本里将近六成用某家云办公邮箱，一成半用另一家，剩下的分散在几家企业邮件安全服务上。这个分布有个实际用途：如果你的收信服务和你的发信服务不是同一家，那么两边的记录很可能是两拨人在不同时间配的，出现冲突的概率显著更高。

实务上见过最典型的冲突是：办公邮箱换过一次供应商，新的引用加上去了，旧的没删，于是记录里同时躺着两家的授权，白白多花两三次查询，而且旧那家的服务器理论上还能用你的域名发信。

这条判据还能搬到哪儿

抽出来看，这篇讲的是同一件事的第二种形态：你写下的那个值，展开之后的实际内容由别人现给，他们随时能改，而改动没有回执。

第一种形态在前端那边的样子是这样的，白名单上写着那个域名浏览器还是把它拦了记录了一次完整的漂移排查。

同样的形状在别处到处都是。前端页面上引用一个第三方脚本，它的内容由对方随时替换；构建时依赖一个开源包，它的依赖树由维护者决定；广告投放里用一个自动化产品，它的匹配范围由平台随时调整。共同点是：你以为自己写的是一个值，实际写的是一个指针。

这篇是第二种。三种的解法不一样，但第一步都相同：先把那个值展开，看看它到底有多长。

展开这个动作本身有个心理门槛：它总会显得多此一举。你明明知道自己写了四行，为什么还要去数？因为你写的是四个名字，实际生效的是四棵树，而树有多大不由你决定。凡是你写下的东西里出现了别人的名字，那一处就必须展开一次才算数完。

最后留一个能立刻做的动作：把自己域名的记录取出来，数一遍里面有几个别人的名字。如果这个数大于三，今天下午就值得花二十分钟把它们逐个展开一遍。这二十分钟的产出，是一个你以前从来没看过、但一直在决定你邮件命运的数字。数出来之后把它写在文档最上面，标上日期，下个季度再数一次，看它涨了没有。涨了，就说明有人替你改过东西，而那个人不会来告诉你。

这套动作不需要预算，不需要立项，不需要说服任何人。它唯一需要的是有人愿意在某个下午打开命令行，把一行本来就存在的记录展开看一遍。这批样本里93个品牌，绝大多数缺的都不是能力，是这个下午。

常见问题解答

查询次数超了，最快的解法是什么？

按三步走。第一步删掉已经不用的引用，多数域名能砍掉一到两个。第二步把最贵的那个上游换成它下面的具体子记录，通常能省两到四次。第三步如果还不够，把最稳定的那家的IP段直接抄进记录里。三步做完还是超，说明真正的问题是工具太多，得从采购侧解决。

群发队列那一侧也有一批影响送达的配置，订阅管理与群发队列实战把发送节奏与队列参数讲清楚了。

为什么我的检测工具说没问题，你说的这些坑它都没报？

多数在线检测工具只查一次，而顶点域名的记录集有概率被截断，工具拿到的可能不是完整答案。另外不少工具只数第一层的引用数量，不做递归展开，这样数出来的结果会明显偏小。判断一个工具靠不靠谱，看它给不给你展开树，给不出来的基本只数了第一层。

多备几把免费的尺子交叉着用，预算为零也能做好的那份工具清单里有几个可以互相验证的选项。

子域没写策略记录，会被冒充吗？

会。任何人都可以用你的域名下一个不存在的子域作为发件人，如果主域策略是不做处理，收件方不会拦。这类冒充在钓鱼里很常见，因为收件人看到的域名后缀确实是你的。给主域的子域标签设成最严一档，是成本最低的堵法，前提是在用的发信子域都已经有了自己的记录。

域名相关的信任继承是把双刃剑，过期域名买来怎么用才能保住信任拆了信号继承的六个判断点。

兜底规则该用软失败还是硬失败？

过渡期用软失败，稳定后用硬失败。软失败的意思是“不在名单上的我也不敢说一定不是我发的”，硬失败是“不在名单上的一定不是我”。样本里将近七成用的是软失败，很多是从一开始就没改过。真正决定拦不拦的其实是域名策略那条记录，兜底规则更像是给它提供的原料，两者要一起看。

软拦还是硬拦这个选择在别处也一样纠结，拦不拦爬虫的三层选型框架给了一个可以复用的决策结构。

营销邮件用服务商提供的子域发，是不是就不用管这些了？

不是。用服务商的子域意味着签名和授权都挂在他们的域名下，你的域名策略确实管不到那部分，但代价是收件人看到的发件域名不是你的品牌域名，长期看会削弱品牌识别，也拿不到自己域名的发信信誉积累。主流做法还是用自己的子域，然后老老实实把授权、签名、策略三样配齐。

品牌身份要落在自己的域名上，这件事在搜索侧同样重要，实体主页怎么搭讲了品牌地基该放在哪儿。

这套查法对国内的邮件环境适用吗？

机制部分完全适用，因为这几条规范是全球通用的。差别在收件方的执行严格程度和报告支持程度上：国内几家主流邮箱对策略的执行力度和报告回传的完整度跟海外不完全一致，所以聚合报告里看到的样本可能偏少。做跨境业务的话，两边都要各测一遍，别用一边的结果推另一边。

国内平台的口径和海外差别不小，搜索资源平台怎么用整理了另一条需要单独适配的链路。

加密传输策略和传输报告值得配吗？

值得，而且成本很低。邮件传输安全策略这套机制的作用是告诉发信方“跟我通信必须用加密，别接受降级”，配置内容是一条解析记录加一个放在固定路径上的文本文件。传输报告则是让对方把加密失败的统计发回给你。这批样本里前者只有3个域名配了、后者6个，都在个位数——典型的“需要自己动手就没人做”。真正的价值不在于挡住多少攻击，在于你能知道有没有人在中间做手脚。

加密这条线上还有一批一次性配置，从明文迁到加密协议怎么才能稳住排名里的检查清单可以顺带跑一遍。

怎么判断一个域名接了哪些发信服务？

看签名记录的选择器。签名规范里规定公钥要发布在选择器名字加固定后缀的子域下，而各家服务商用的选择器名字相对固定，探一遍常见的几个就能大致判断。这个方法对自己的域名尤其有用：探出来的选择器如果有你不认识的，说明有人配过一个你不知道的发信渠道。

理清有几个渠道之后，下一步是理清各自该发给谁，用户分群的七个维度与避坑给了一套分群口径。

批量发信有没有明确的门槛要求？

有。主流邮箱服务商已经把授权、签名、策略三样列成了批量发件人的最低要求，达不到的会被限流甚至拒收，同时还对退订方式和投诉率设了硬指标。这些要求最近两年在收紧，而且执行方式是静默的——不达标不会有人通知你，只会表现为送达率慢慢往下掉。

续费提醒这类交易邮件对送达最敏感，订阅商品、定期扣款与续费失败挽回说明了漏一封的代价有多大。

这批数据能代表什么？

它代表的是北美中大型DTC品牌在2026年8月这一天的状态，样本95个，抓取方式是公开的域名查询，没有任何内部信息。它不能代表中小卖家，也不能代表B2B企业——后者的工具栈通常更长，超限比例很可能更高。这批数字真正有价值的是那个结构：查询成本跟记录长度无关，跟你引用了谁强相关。

样本边界要在结论之前说清楚，以消费级三维打印机为例完整拆一遍那篇给了一个交代口径的范本。

权威参考资料