邮件传输加密：130个站都支持，不给降级机会的只有1个

摘要：把130个英文大牌的收信服务器逐台连上25端口问了一遍，没有一台拒绝加密——130台全都主动宣告支持STARTTLS，其中129台完成了TLS握手，122台用的是TLS 1.3。但这份好看的数字有个前提：加密是对方“愿意”给的，不是你“要求”的。真正用MTA-STS把明文回退这条退路堵死的，130个站里只有1个。

先说清楚这篇在测什么。不是你发出去的信别人收不收得到，那是投递率的事；是别人给你发信的时候，信在路上那一段到底加不加密，以及那层加密能不能被人不动声色地掀掉。

这两件事经常被混成一件。域名根上那几条SPF记录、DKIM签名、DMARC策略，管的都是发件方向：谁有资格用你的域名往外发信。围绕发件做的功课通常也很足——投递率掉一个点会有人追，Gmail那边一改规则（比如一键退订必须写两层）全公司都得动。

收件方向反而没人管——你把MX记录一填，邮件就开始往里进了，进来的路上加不加密，取决于对方那台服务器的心情。没有KPI会因为这件事掉下去，所以也就没有人去看。

这一轮我把131个英文大牌站点的域名拿来，先用DNS over HTTPS查MX记录、MTA-STS声明、TLS-RPT回执地址和DS记录，再按MX优先级取出每个站真正的收信主机，逐台连上25端口，握手取证书，最后把DNS里的声明和服务器上的实际行为两边对账。

一封信送到你手上之前，那一段路是加密的吗？

答案是：几乎肯定加密了，而且这个“几乎肯定”一文不值。

SMTP这个协议1982年定稿的时候压根没有加密。后来打的补丁叫STARTTLS，写在RFC 3207里，做法很朴素：双方先用明文连上，发信方问一句“你支持加密吗”，收信方在能力清单里回一句“支持”，发信方再说“那我们加密吧”，然后才开始TLS握手。

问题就出在这个顺序上。协商本身是明文的。中间任何一个能改数据包的人，只要把收信方那份能力清单里的STARTTLS这一行删掉，发信方就会认为对方不支持加密——而按照默认规则，它不会因此拒发，它会退回明文，把整封信原样送出去。

这套设计有个专门的名字，叫机会性安全，标准文本是RFC 7435。它的立场写得很坦白：有加密就用，没有就算了，总比完全不加密强。这话在2014年是对的，那年全球邮件的加密比例还很低，先把大盘拉起来最要紧。

这是一种典型的默认值设计——不表态的时候，系统替你选最宽松的那一档，理由是宽松的那一档不会把事情搞砸。同样的逻辑在别处也见得到：robots.txt的分组不继承、Cookie不写SameSite时的那两分钟宽限，都是同一个思路。宽松档的好处是不出事，代价是你以为自己有的保护其实没有。

但机会性安全有个隐含前提经常被忽略：它防的是被动窃听，不防主动篡改。一个只能看不能改的人拿你没办法；一个能改包的人，把那一行删掉就行了，你这头收到的信和平时一模一样，日志里不会有任何异常，因为在你的服务器看来，对方就是一台不支持加密的老服务器。

130台收信服务器，一台台问过去得到了什么？

131个域名里，braun.com没有MX记录（它的邮箱走别的域），剩下130个都能定位到收信主机。按优先级数字最小的那台算，130个站落到69台唯一主机上——很多品牌共用同一个平台入口。

逐台连过去，结果整齐得有点无聊：

• 130台全部主动宣告支持STARTTLS，一台例外都没有。
• 其中129台完成了TLS握手，TLS 1.3有122台，TLS 1.2有7台，没有一台还在用更老的版本。
• 剩下那1台是shein.com的收信服务器，它宣告了STARTTLS，也对命令回了“220 Ready to start TLS”，然后在握手那一刻把连接掐断了。换三次、隔开时间再试，三次行为完全一致。

如果只看第一行，这份成绩单堪称完美：加密覆盖率100%。做安全审计的人最该警惕的就是这种数字——上一轮做证书透明日志的时候我就写过，第一版跑出一组特别整齐的数字，通常意味着你把一批不同的东西粗暴地归进了同一格。

这次的“同一格”是：我把“它说它支持”和“它必须支持”当成了一件事。

顺便看一眼这69台主机后面站着谁。Google的收信入口覆盖56个站，微软覆盖37个，两家加起来93个，占130个站的71.5%。剩下的分给Proofpoint（8个）、Mimecast（6个）、阿里云与万网系（4个）、趋势科技（3个）、Barracuda（3个），以及零星的自建。

banner那一行泄露的信息也不少。theordinary.com的收信入口是Mailgun，quince.com直接挂在Amazon SES上，byredo.com的MX指向母公司Puig的域名、实际应答的却是思科IronPort的云网关，dji.com那台自报家门是Softnext-ESG（中国台湾一家邮件安全网关厂商）。这些细节和之前测HTTP响应头时看到的规律一样：真正在干活的那个组件，往往不是品牌自己选的那个牌子。

69台主机撑起130个品牌，证书上印着谁的名字？

130个站落到69台唯一收信主机上，这个比例本身就说明了问题：接近一半的品牌，收信入口和别人是同一台。

微软那套的做法是给每个租户一个专属主机名，uniqlo-com.mail.protection.outlook.com、philips-com.mail.protection.outlook.com、underarmour-com.mail.protection.outlook.com，看上去一家一台。但把证书取下来对一对就露馅了：这些主机出示的是同一批证书，SAN列表都是34条，内容一模一样。名字是给每个租户单独发的，机器是共享的。

Google那边更直接，56个站的收信入口全都指向aspmx.l.google.com这一组固定主机名，连表面功夫都不做，证书SAN是26条Google自己的域名。

最值得看的是阿里系那几台。aliexpress.com的mx2.mail.aliyun.com、ecoflow.com的mx1.qiye.aliyun.com、govee.com和narwal.com共用的mxn.mxhichina.com，三台机器出示的是同一张证书，SAN列表231条，而且不用通配符，一个名字一个名字明写。翻一遍这231个名字，里面躺着alimailws.alibaba-inc.com、alimei-api-40.alibaba.com、alimei-auth.aliyun.com、alimei-api-sg.aliyuncs.com这类内部服务名，顶级域分布是221个com、8个cn、2个sg。

一张证书把一整套内部服务的命名规则、地区分片和接口划分公开印了出来，任何人连一次25端口就能全部拿走。上一轮做证书透明日志的时候，网页那侧的SAN也暴露过同类东西——区别是网页证书还会被公开日志收录、有人盯着，邮件网关这张没人看。

这一节和加不加密无关，但它决定了后面所有结论的性质：你的收信链路上，绝大部分部件不是你的。Google和微软两家覆盖了71.5%的站，它们的证书由它们签、TLSA记录由它们发、支持哪个协议由它们定。你能决定的，只有你自己域名上那几条记录。

“支持加密”这句话，能不能被中间的人删掉？

能。而且删起来毫无技术含量。

要堵住这条路，办法是让发件方在连接之前就知道“这个域名要求必须加密”，这样即便中间人把STARTTLS那行删了，发件方也会因为拿不到加密通道而直接拒发，不会退回明文。

做这件事的机制叫MTA-STS，标准是RFC 8461。它的结构挺有意思，一份策略要分三处才算完整：

1. DNS里放一条声明：在_mta-sts.你的域名上放一条TXT记录，内容是v=STSv1; id=某个版本号。这条只说明“我有策略，版本号是这个”，不含策略内容。
2. HTTPS上放一份策略文件：地址固定为https://mta-sts.你的域名/.well-known/mta-sts.txt，里面写清楚mode是什么、允许哪些MX主机名、缓存多久。
3. 这个mta-sts子域必须有一张有效证书：因为发件方是通过HTTPS去取这份策略的，证书验不过，策略就等于不存在。

三处缺一不可，而且它们分属三个系统：DNS一处、Web服务器一处、证书一处。这个分散度本身就是MTA-STS铺不开的原因之一——它不是在某个后台里点一个开关，它要三个团队各做一件事。

顺带说一句，这套路数在网页那边有个亲戚，叫HSTS：同样是“我提前告诉你，以后只准用加密来找我”。区别在于HSTS只要加一个响应头，MTA-STS要动三个地方。谁铺得开谁铺不开，光看这一条就能猜出个大概。

真正不给降级机会的，为什么只有一个站？

131个域名查下来，_mta-sts上写着有效声明的只有3个：ikea.com、notino.com、ritual.com。

三份策略文件我都取回来了，全文照抄：

# ikea.com
version: STSv1
mode: testing
mx: ikea-com.i-v1.mx.microsoft
max_age: 86401

# notino.com
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

# ritual.com
version: STSv1
mode: enforce
max_age: 31449600
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: aspmx2.googlemail.com
mx: aspmx3.googlemail.com

关键在mode那一行。RFC 8461定义了三档：enforce是真的执行，验不过就拒发；testing是只记录不拦截，验不过照样投递、顺手发一份报告给你；none是明确宣布作废。

3个站里，2个停在testing，只有ritual.com一家是enforce。也就是说，130个站里真正把明文回退这条路堵死的，是1个，占0.8%。

testing这一档很值得多说两句。它在纸面上不是错误配置，官方推荐的上线路径就是先testing跑一段、收着报告确认没有误伤，再切enforce。问题是这个“一段时间”有多长。

三份文件里的id字段给了一点线索。ritual.com写的是20240119T055225，notino.com写的是2026021201，两个都是明摆着的日期格式；ikea.com写的是1751618879951，按毫秒时间戳解出来是2025年7月4日。这里要说清楚：RFC 8461只规定id是1到32位的字母数字，没有要求它必须是时间戳，所以这只是形态上的推测，不能当结论用。

但把这个推测和mode放在一起看，画面就有点意思了：那份写着testing的策略，从版本号上看已经挂了一年多，还停在“我先看看”的阶段。而唯一切到enforce的ritual.com，版本号停在2024年1月——它两年多没动过这份文件，因为不用动，它已经到位了。

max_age那一栏也在讲同一个故事。ritual.com写的是31449600秒，364天；两个testing的站写的是86400和86401，正好一天。缓存一天意味着策略随时可以撤，撤了第二天全网就忘干净——这是给自己留的后门，也是没打算长期跑的信号。

我原以为是证书对不上，实测把这个猜想打掉了

看到2个testing的时候，我的第一反应是：大概是不敢切。切到enforce之后，发件方会去校验收信主机的证书，万一有哪台机器的证书名字对不上，信就真收不到了——收不到客户的邮件，这个后果谁也担不起。这个解释听着特别顺。

所以我把它当成一个可以证伪的假设去测了：既然enforce要校验证书上的名字，那就把129台完成握手的服务器证书全取下来，逐台看MX主机名在不在证书的SAN列表里。这正是enforce模式下发件方要做的那道校验。

结果是：127台对得上，只有2台对不上。

换句话说，绝大多数站就算今天把mode改成enforce，证书这一关也是过得去的。技术上没有那道拦路虎，我原来那个解释站不住脚。

这是本轮最值得记下来的一次修正。它把结论从“有客观障碍所以做不了”，改成了“没什么障碍，就是没人做”——后者难听得多，但它才是实测出来的那个。

那到底为什么没人做

把技术障碍排除之后，剩下的解释只能到别处去找。我能想到的有三条，而且三条都不是技术问题。

第一条，没有任何外部力量在推。SPF、DKIM、DMARC这几年铺得飞快，不是因为大家突然有了安全意识，是因为Gmail和Yahoo在2024年划了线：不配就限流。收件方向没有这样一条线。你不配MTA-STS，没有任何一家邮件服务商会因此少收你一封信，也没有哪个合规框架点名要求它。一件事没有被强制，就只能靠自觉，而自觉在企业里是最不稳定的一种资源。

第二条，出了事你也不会知道。降级攻击的特征是无声无息：你的服务器照常收信，日志里是一次正常的连接，只不过没走TLS。除非你配了TLS-RPT，否则这件事在你的可观测范围之外——而TLS-RPT本身也得先配。这构成一个闭环：你需要先做这件事，才能知道自己有多需要做这件事。这类闭环在工程里通常都以“没人做”收场。

第三条，它的KPI归属不明。发信那一头挂在市场部或增长团队名下，投递率是他们的数字，掉了有人急。收信这一头属于IT，而IT的考核指标里通常只有“邮件能不能正常收发”，加密与否不在其中。一件事没有主人，它就永远排在待办列表的下半截。

三条合起来，130比1这个数字就不奇怪了。奇怪的反而是那1个：ritual.com把max_age写成364天、版本号停在2024年1月——有人在两年多前认真做完了这件事，然后再也没碰过它。这是配置该有的样子。

对不上的那2台，各有各的看点，下一节单独说。

有一台收信服务器的证书，两年前就过期了

dji.com的MX指向mail.djicorp.com。连上去，STARTTLS宣告了，握手也成功了，取下来的证书长这样：

• 主体名和签发者名完全相同（CN=dd40882ba0ea），也就是一张自签证书；
• SAN列表一条都没有，连它自己的主机名都没写；
• 签发于2014年9月15日，有效期截止到2024年9月12日。

按本轮实测的2026年9月2日算，这张证书已经过期720天。连了三次，三次拿到的是同一张，指纹一字不差。

这个例子把机会性加密的荒诞之处摊得明明白白：加密在跑，而且跑得好好的，因为根本没有人去看这张证书。STARTTLS的默认玩法就是不校验——反正验不过也是退回明文，那还不如不验直接加密，好歹能挡住被动窃听。于是一张过期两年、没有任何身份信息的自签证书，照样每天在替这个域名加密着所有进来的邮件。它加的密在密码学上是货真价实的；它证明不了对面是谁，一点都证明不了。

另一台是byredo.com。它的MX指向母公司Puig的域名mail-ib-1.puig.com，实际应答的却是思科IronPort托管网关，证书主体写着CN=mx1.hc1069-92.c3s2.iphmx.com，SAN里8个名字全是iphmx.com和cisco.com下面的，没有一个和puig.com沾边。

这不是配错了，这是没配。用云邮件网关的时候，把自己的域名CNAME到服务商的入口再给它签一张证书是要额外做一步的，多数人不做，因为不做也能收信。只有在有人真的去校验的那一刻，这一步的价值才会显现——而现在，没有人校验。

顺便说一句，dji.com的这张证书要是长在网站上，早就被浏览器拦下来了，用户会看到一整页红色警告。同一个组织，同一批人管的基础设施，网页那头的证书必然是新鲜有效的（否则生意做不成），邮件这头挂着一张2014年的自签证书没人管——差别不在能力，在有没有人盯着。这一点和之前测支付页CSP时看到的是同一个道理：配了不代表在管事。

DANE这条路，为什么56个站根本走不上去？

MTA-STS不是唯一的解法，还有一条更早的路叫DANE，标准是RFC 7672。思路完全不同：MTA-STS把策略放在HTTPS上、靠证书体系来证明；DANE把收信主机的证书指纹直接写进DNS，靠DNSSEC签名来证明。不用CA，不用HTTPS，一条TLSA记录搞定。

听起来更干净，实际铺得更慢。原因在于它有两个前提，而且分属两个主体：

1. 收信主机那一侧要发布TLSA记录——这件事由邮箱平台做，你做不了；
2. 你自己的域名和平台的域名都要签了DNSSEC——不然那条TLSA记录本身就可能被伪造，写了等于没写。

实测下来，130个站里MX主机带TLSA记录的只有2个：assos.com和ikea.com，它们的收信入口都在微软的mx.microsoft域下，而这条TLSA是微软发的，不是这两家品牌发的（微软在自己的文档里写明了这套记录由平台侧发布与轮换）。巧的是，这2个站恰好也是自己签了DNSSEC的——两个前提由两方各满足一个，凑齐了。

再看另一头就更清楚了。我把各个邮箱平台自己的域名拿去查DS记录，两个DNS服务商各查一遍对账，结果一致：

• outlook.com、mx.microsoft、pphosted.com：签了；
• google.com、googlemail.com、mimecast.com、barracudanetworks.com、aliyun.com、qq.com：没签。

用Gmail收信的那56个站，DANE这条路是彻底走不通的，不管它们自己多努力——因为google.com自己没签DNSSEC，收信主机在DNS里根本没法证明自己。这56家品牌里但凡有谁认真研究过DANE，最后都会得到同一个结论：这件事不由我决定。

这就是本轮最想说的那句话的第一个落点：你能不能做成一件事，一半的开关不在你手上。

只装了报警器没装锁，是什么状态？

和MTA-STS配套的还有一个东西叫TLS-RPT，标准是RFC 8460。它的作用是让发件方每天把“我给你发信时加密成功了几次、失败了几次、为什么失败”汇总成一份报告寄给你。

131个域名里配了TLS-RPT的有5个：ikea.com、notino.com、ritual.com、monos.com、philips.com。

前三个是配了MTA-STS的那三家，顺理成章。后两个有意思：monos.com和philips.com配了TLS-RPT，却没有配MTA-STS。

这个组合翻译成人话是：我装了个报警器，但门上没锁。报告会一天天寄过来，告诉你今天又有多少封信是明文送达的，而你手上没有任何机制去改变这件事——因为你没声明过要求加密，发件方也就没有义务加密。

收报告的地址也值得看一眼。ikea.com寄到MTA-STS.RUA@ikea.com、notino.com寄到tlsrpt@notino.com，是自己收；ritual.com寄到easydmarc的地址、monos.com寄到mailhardener、philips.com寄到tls-report@vali.email，是交给第三方服务商解析。5家里3家把回执交给了外面的人。

这个比例本身不算问题，报告是结构化的JSON，交给专业工具解析比自己写脚本靠谱。但它和之前查域名验证记录时看到的现象是一回事：域名根上每多一条记录，就多一个外部依赖，而这个依赖通常没有台账、没有到期提醒、也没有人定期复核它还在不在服务。第三方组件会自己变，而变的那一天不会有人通知你。

还有一层更细的：ikea.com和ritual.com的_mta-sts那条TXT并不是直接写在自己域上的，而是CNAME委托出去的——ikea指向_mta-sts.smart.ondmarc.com，ritual指向ritual_com__mta_sts.easydmarc.pro。这意味着策略的版本号由服务商掌握，续不续、改不改，取决于合同还在不在。上一轮查CAA记录时也是同样的形态：查得到的那份配置，主人常常不是品牌自己。

这一轮，我的尺子错在哪几处？

四处，其中两处改变了结论方向。

第一处：8个站看着配了一半，其实一个字都没配

第一遍抓策略文件的时候，除了3个正常返回的，还有一批很暧昧的结果：bollandbranch.com、on.com、shopify.com三个站返回404，graza.co和rab.equipment的证书验不过，aliexpress.com返回302跳到自己的错误页，functionofbeauty.com返回503，zalando.com更绝——返回200，但content-type是text/html，正文48385字节，是一整张网页。

按字面读，这8个站都属于“建了mta-sts子域但没放对文件”，也就是配了一半。这个结论我差点就写下去了。

幸好补了一个对照实验：拿一个绝对不存在的子域名（zzq-nonexistent-104-probe.域名）去查A记录。8个站全部有解析。而3个真配了MTA-STS的站，同一个随机子域查过去，一条记录都没有。

真相是这8个站配了泛解析：*.域名指向主站。于是mta-sts.域名自动就有了地址，请求打到主站的Web服务器上，得到的是主站对一个未知路径的常规反应——404、跳转、503，或者zalando那种返回200的软404页面。它们不是配了一半，它们一个字都没配，是泛解析让子域看上去存在。

这个坑值得记牢：只要一个域名开了泛解析，任何“子域存在与否”的判断都会失真，得先拿随机子域打一发基线。之前测子域名清单和软404的时候都碰过这类问题，这次换了个壳子又来了一遍。

再往上抽一层，这和测Vary响应头时踩的是同一个坑：拿到一个非空的答案，就默认这个答案是关于你问的那个问题的。实际上服务器只是对任何请求都给点什么，你问什么它并不关心。响应头自相矛盾那一轮也是，两个字段各说各话，是因为它们由两个互不知情的组件写下的。

第二处：把“它说它支持”当成了“它真能加密”

第一版统计里我拿EHLO能力清单里有没有STARTTLS这个字符串来算覆盖率，算出来130台全支持。shein.com那台就藏在这个数字里：它宣告了，也对STARTTLS命令回了220，然后在TLS握手那一步把连接掐了，三次复测行为一致。

严格说这不算“支持”。修正后的口径是：130台宣告，129台真正握上手。差别只有一台，但这一台恰好是整篇文章论点的活标本——宣告和实际是两回事，而这一次栽在这个坑里的是我自己。

第三处：拿证书指纹当站点属性，差点写出一个假差异

做稳定性复测的时候，20台主机里有7台两次拿到的证书指纹不一样。第一反应是发现了什么大新闻。

拉开看，7台全是微软那组品牌-com.mail.protection.outlook.com的主机，两次指纹在两个固定值之间来回跳，而STARTTLS宣告和SAN匹配两项判定完全一致。挑一台连续连6次，结果是8a8d…和e0c3…交替出现，两张证书都能匹配上主机名；同样连6次的aspmx.l.google.com则始终是同一张。

结论是微软那个入口后面至少有两台机器，各持一张证书，负载均衡随机分配。要是我拿指纹去比对“不同品牌是不是用了不同证书”，会得到一堆纯属噪音的差异。这条判据的复核方式还是那一条：任何“A和B不一样”的结论，先问一句“A和A自己一样吗”。

第四处：一次连不上就当人家不支持

第一轮有一台Barracuda的网关超时，第二轮重试仍失败，第三轮通了，TLS和证书全都正常。被拦或者超时是概率事件，不是站点属性——这一条我上一轮刚记过，这一轮又碰上了，说明重试补分母这一步不该等出问题再做，应该写死在流程里。

还有一件事得说在前面：POST方向的行为本轮一个都没测。要判断一台服务器是不是真的会拒收明文投递，唯一的办法是真的对它发起一次不加密的投递尝试，那是对别人的生产系统做写操作，不能干。所以本文所有结论都止步于“连接、协商、握手、取证书”这四步，再往后的行为一律没有实测数据。

自己的域名该怎么查？

不用装工具，三条命令十分钟能查完。

第一步，看自己有没有声明。

dig +short TXT _mta-sts.你的域名
dig +short TXT _smtp._tls.你的域名
curl -sI https://mta-sts.你的域名/.well-known/mta-sts.txt

三条全空，说明你在这一层是完全默认状态：任何人给你发信，加不加密由对方决定，被降级了你也不会知道。顺便一提，如果连MX都查不出来或者解析很慢，那就是另一码事了，先去排查DNS这一层。

第二步，看自己的收信服务器怎么应答。

dig +short MX 你的域名
openssl s_client -starttls smtp -connect 你的MX主机:25 -servername 你的MX主机

重点看三样：证书上的名字里有没有你的MX主机名、有效期还剩多久、签发者是谁。如果像本文那台那样是自签的、或者名字完全对不上，那么今天先别切enforce，先把证书这件事和邮箱服务商对齐。

第三步，如果决定要上，顺序别搞反。

1. 先把TLS-RPT配上，让报告先跑起来，这一步零风险，纯粹是加一双眼睛；
2. 收两三周报告，确认没有持续失败的发件方；
3. 再发布mode: testing的策略，同时确保mta-sts子域的证书在你的续期流程里，别漏了它——这台机器上的证书过期，整份策略当场失效，而这件事不会有任何人提醒你，参见证书有效期正在往47天砍这个大背景；
4. testing跑满一个完整的业务周期（包含月末、大促这类邮件高峰），报告干净了，再改成enforce；
5. max_age一开始别写太长，从86400起步，稳定之后再往上加到几周、几个月。写成一年的前提是你确信这份策略不需要临时撤回。

另外提醒一句：如果域名开了泛解析，第一步的curl大概率会返回一个200的主站页面，看着像配好了。判断标准不是有没有响应，是响应体第一行是不是version: STSv1，以及content-type是不是text/plain。zalando.com那个48KB的HTML就是活教材。

最后说说值不值得做。保哥的看法是：不必用“防住了多少次攻击”来算这笔账，针对特定品牌的邮件降级攻击本来就不常见，真按次数算，这笔投入永远算不平。

值得做的理由是另一个。你的域名根上已经躺着十几条各式各样的记录，其中多数是别人让你加的，加完就没人再看。MTA-STS是少数几个反过来的：加完之后，这条链路从“大概是加密的”变成“确定是加密的”，出了岔子会有报告寄到你邮箱里。把一件不可观测的事变成可观测的，这个收益不用等到出事才兑现。

本轮通篇看下来，最扎眼的其实不是那个1，是那张2014年签发、2024年到期、今天还在替一个品牌加密所有来信的自签证书。它一天没出过故障，因为从来没有人要求它证明自己是谁。默认状态就是这样：它不报错，它只是把标准降到了你不会注意到的高度。

常见问题解答

没配MTA-STS，我的邮件就是明文传输的吗？

不是。本轮实测130台收信服务器全都宣告支持STARTTLS，129台真正完成了TLS握手，正常情况下邮件是加密传输的。区别在于这份加密是对方自愿提供的，不是你强制要求的：路径上有人主动篡改协商过程时，发件方会静默退回明文，而你这头看不出任何异常。MTA-STS解决的正是这个“静默”问题。

MTA-STS的testing模式有用吗，还是等于没配？

有用，但用处只有一半。testing模式下发件方会照常投递，同时把校验结果写进报告寄给你，所以你能提前发现哪些发件方会失败、失败在哪一步，这是切enforce之前的必要准备。但它不拦截，也就不提供任何强制加密的保证。本轮3个配了MTA-STS的站里有2个停在testing，从策略里的版本号形态看，其中一个已经停了一年多。

用Gmail或Microsoft 365收信，还需要自己配吗？

需要，因为MTA-STS策略是绑在你的域名上的，不是绑在平台上的。平台负责让收信主机的证书是有效的、名字是对得上的（本轮实测127台证书名字都对得上），但DNS里那条TXT声明、HTTPS上那份策略文件、以及mta-sts子域的证书，这三样都得你自己准备。反过来说，正因为平台这一侧已经做好了，你这一侧的工作量比想象中小。

MTA-STS和DANE该选哪个？

先看你的邮箱平台支持哪个，这一条基本能替你做完决定。DANE要求收信主机发布TLSA记录、并且平台域名签了DNSSEC，本轮实测中google.com没有签，所以用Gmail收信的56个站没得选，只能走MTA-STS；微软那一侧两个条件都具备，可以两条路都走。两者不冲突，同时配上是推荐做法。

配了之后会不会导致收不到邮件？

testing模式不会，它不拦截任何投递。enforce模式存在这个风险，触发条件是发件方无法验证你的收信主机身份——比如证书过期、证书上的名字和MX主机名对不上、或者策略文件里漏写了某台MX。所以切换前必须做两件事：核对策略里的mx清单和真实MX记录完全一致，以及确认每台MX主机的证书名字都能对上。本轮130个站里，有2台服务器的证书名字对不上，它们如果直接切enforce就会真的收不到信。

mta-sts这个子域，用现有的Web服务器承载可以吗？

可以，但要注意三点。一是它必须有独立且有效的证书，主域的通配符证书能不能覆盖取决于证书本身，得实际验一遍；二是策略文件的content-type必须是text/plain，用默认的静态目录托管通常没问题，但如果被前端框架接管了路由，很容易变成text/html；三是RFC明确规定发件方不得跟随重定向，所以这个地址不能配成301或302跳到别处，本轮就有一个站的请求被跳去了主站的错误页。

怎么知道有没有人真的在用它？

配上TLS-RPT就知道了。报告里会写明每个发件方的连接总数、成功数、失败数和失败类型，通常一天一份。这也是本文建议把TLS-RPT放在第一步的原因：它零风险、零副作用，而且能在你还没做任何强制之前，先让你看见这条链路上真实发生了什么。

权威参考资料