成人分类广告网站的邮件送达率:验证码为什么总是收不到

一个没人会收到警报的故障

一位新用户注册,输入邮箱地址,等待那组能让他完成年龄验证的六位数字验证码。它没有在该到达的那一分钟内到达。也许十分钟后它出现在垃圾邮件文件夹里,那时用户早已放弃并关掉了页面。也许接收邮件的服务器在发送的那一刻就直接拒收,退信记录悄悄划过一个没人在看的日志。无论哪种情况,整个过程都没有任何迹象告诉运营者出了问题。注册漏斗只是多显示了一位填了邮箱地址却再也没回来的访客,和一个单纯改变主意的人没有任何区别。

这种模糊性才是真正的问题所在,比任何单一的技术原因都更棘手。大多数网站监控的是邮件有没有发出去,后台面板上的一个绿色对勾,而不是邮件有没有真正出现在一个活人面前。这是两件不同的事,而两者之间的落差,正是送达率问题能够藏上几个月的地方。一个从未经历过主机故障或支付通道冻结的运营者,仍然可能因为一个自己根本无从察觉的邮件问题,持续流失相当一部分新注册用户,因为这里没有事故,没有工单,也没有变红的仪表盘。

这是一种和另一种风险不同的供应商风险,后者会用一封援引某条早已没人重读过的条款的通知,直接关闭主机账号。被暂停的主机是响亮的:网站瞬间下线,运营者几分钟内就会知道,因为客户会说,后台面板也会显示。而送达率问题从设计上就是安静的。发信账号照常开着,月度账单照常寄来,唯一能看到的症状是一个在最后一步流失用户的注册漏斗,而从运营者这边看,这看起来就像普通的用户流失,不像一个可以修复的技术故障。

根本原因仍然是同一种在主机、银行和支付处理商那里都会出现的分类摩擦。邮箱服务商和邮件发送服务把这个行业类别评为高风险,有些甚至明确点名,一个没有发送历史的新域名,从第一封邮件开始就带着一种和邮件内容本身毫无关系的劣势。

为什么这个行业类别被过滤得比大多数行业更狠

垃圾邮件过滤器和邮件服务商并不平等对待每个行业,这些差异最好在注册之前读清楚,而不是等到账号被标记之后才明白。SendGrid 自己发布的禁止内容政策把「色情或性暗示内容」和「陪伴服务、邮购新娘或配偶搜寻、跨国婚介机构及类似服务」分列为两条独立条款。第二条和邮件里写了什么无关。它把这门生意本身列为排除理由,这意味着一个由陪伴目录网站发出的、内容平淡的纯文本验证码,仅凭行业类别就可能落在政策之外,无论这封信本身有多克制。

Mailgun 的可接受使用政策把界线画在了完全不同的地方。它关于禁止内容的条款只限于构成或宣扬儿童剥削、兽交或非自愿性行为的材料,并没有单独一条把成人行业或陪伴服务列为一个类别。这比 SendGrid 的限制要窄得多,针对的是违法内容本身,而不是发信方所处的行业。两家可以通过同样类型的注册表单接入的大型通用服务商,把界线画在了真正不同的位置,一个没有读完定价页面之外内容就选定其中一家的运营者,根本无从知道自己的账号落在界线的哪一侧,直到某次审核揭晓答案。

这和运营者从未读过就被主机或 CDN 终止条款打个措手不及,是同一种尽职调查上的盲区,只是发生在堆栈更下面的一层。选邮件服务商之前该问的问题,不是它是否在技术上笼统地允许这类生意发信。而是这家服务商的书面政策是否明确点名了这个行业类别,白纸黑字,在第一条验证码发出去之前问清楚,而不是等到滥用审核发现之后。

一个新的发信域名会在服务商本身允许的范围之上,进一步加重这个问题。过滤器高度依赖域名的历史和发信量模式,一个最近才出现、立刻就开始大量发送自动验证码的域名,在没有其他信号的过滤器眼里,看起来就像一个为狭窄目的而创建、一旦被标记就会被抛弃的账号模式。这不是对这门生意的评判;这是任何全新域名都会触发的模式匹配,无论是不是成人分类广告,只有靠时间和持续稳定的发信行为才能慢慢淡化。

现在每家邮箱服务商都在强制执行的技术底线

即便一家服务商的政策毫无保留地接纳了这个账号,它自己也没法单独让一封邮件落进收件箱。自 2024 年 2 月 1 日起,谷歌要求每一个向 Gmail 地址发信的发件人,不论发信量大小,都要满足一条有文档记录的底线:至少要在发信域名上正确配置 SPF 或 DKIM 其中之一。SPF 列出了哪些服务器有权代表这个域名发信;DKIM 给每封邮件签名,让接收服务器能确认它在传输途中没有被篡改。而每天向 Gmail 地址发送量达到五千封的发件人,面对的门槛更高:SPF 和 DKIM 必须同时具备,再加上在该域名上发布 DMARC,至少要处于监控模式。一个真正按规模发送年龄验证码、密码重置邮件和付款收据的分类广告网站,很快就会跨过这个五千封的门槛,因为每一封都算在总数里。

谷歌自己发布的指南在身份验证之上又设了一个硬性数字:不论规模大小,发件人都必须把 Postmaster Tools 里报告的垃圾邮件投诉率控制在 0.30% 以下,同一份指南还建议把这个数字压到 0.10% 以下作为真正的安全余量,而不是把 0.30% 当成一个可以放心贴近的目标。不合规会表现为两种彼此独立、各自有文档记录的故障,而不是一种模糊的惩罚。未通过 SPF、DKIM 或 DMARC 验证的邮件,可能被标记为垃圾邮件,或者直接被 5.7.26 这个 SMTP 错误拒收。超出谷歌允许发信配额的发件人,会撞上另一堵墙,4.7.28 限速错误。这两种情况都不会宣告「这个行业在这里不受欢迎」。从开发者的仪表盘看,两者都像一个普通的技术故障,这正是它们往往在几周之后才被注意到,而不是在出现的当天就被修复的原因。

雅虎的基础设施同时服务于 AOL 地址,它独立发布了同样形式的要求:SPF 和 DKIM 同时具备,至少 p=none 且必须通过验证的 DMARC 政策,以及同样 0.30% 的投诉率上限,和谷歌一样自 2024 年 2 月起生效。一个为 Gmail 解决了这个问题、并假设雅虎和 AOL 会跟着一起达标的运营者,在机制上通常是对的,因为这两家服务商已经趋近于几乎相同的数字,但两套系统仍然各自独立地测量和执行规则,所以一个域名在其中一家那里状态良好,并不意味着在另一家那里自动也良好。

这一整套要求里,有一条是刻意写得很窄的。使用 List-Unsubscribe 邮件头的一键退订要求,按谷歌自己的措辞,专门适用于营销邮件和已订阅邮件。验证码或付款收据都不属于这两类,所以这一条针对的根本不是它们。而它上面那些身份验证和信誉方面的要求,SPF、DKIM、DMARC 以及投诉率上限,并没有被这样限定:它们适用于一个域名发出的每一封邮件,交易类邮件也不例外。

那个会把重要邮件一起拖下水的错误

运营者破坏自己验证邮件最常见的方式,就是用发送验证码和付款收据的同一个域名去发营销邮件。信誉主要是按发信域名和子域名来追踪的,这也是为什么把不同用途的邮件流分开会有帮助,但子域名之间的隔离并不是绝对的:一个子域名上的投诉激增,仍然可能反映到父域名上,尤其是当两个邮件流在幕后共用同一个 DKIM 签名身份的时候。一封宣传新功能或季节性优惠的推广邮件,发给一份已经过时的名单,恰恰会产生那种能拖垮共享域名信誉的投诉激增,而这份损害的一部分,会波及此刻正被一位刚注册用户等待着的验证码,一封和引发问题的营销邮件毫无关系的邮件。

也正是在这里,围绕年龄验证建立起来的运营纪律和一个纯技术性的邮件投递问题交织在一起,而这种交织很容易被忽视。一个依赖验证码抵达收件箱的验证流程,其可靠程度取决于验证码发出那一天发信域名的信誉,而信誉是一种在所有使用相关基础设施的邮件类型之间共享的资源,除非运营者刻意把它们分开。

解决办法是结构性的,不是等投诉激增已经发生之后才去调的一个开关。把交易类邮件,验证码、付款确认、密码重置,放到一个专用的、不做任何其他用途的子域名上发送,比如用 mail.example.com 而不是裸域名或共用的营销子域名,并且用它自己独立的 DKIM 密钥签名,而不是所有邮件流共用一把。把营销内容或新闻通讯从一个完全独立的子域名发出,比如 news.example.com,拥有自己的身份验证记录和自己的信誉,能够承受糟糕的一周投诉量,而不会把必须送达的邮件一起拖下水。这两条邮件流可以走同一个服务商账号,但在接收邮件服务器眼中,它们需要看起来,也需要被签名成,两个明显不同的发件人。

这周真正应该检查的事

先把目前正在发送网站交易类邮件的服务商的可接受使用政策找出来,白纸黑字地确认它是否明确点名了这个行业类别,就像之前对主机和 CDN 合同所做的检查,对基础设施供应商同样有效。一家政策已经点名排除这个类别的服务商,不是一个可以在其上搭建验证流程的服务商,不管它到目前为止有多可靠,因为一次账号审核可以在没有任何预警的情况下终结这种可靠性。

检查 SPF、DKIM 和 DMARC 是否真的发布在,并且真的通过验证于,此刻正在发送验证邮件和收据邮件的那个域名上,而不是想当然地以为它们没问题,只因为有人多年前配置过一次。一条在写下时是正确的 DNS 记录,可能在服务商迁移之后就过时了,而一个缺少身份验证的域名,在谷歌和雅虎自 2024 年 2 月起执行的规则下,每一封邮件从一开始就带着真实的被拒收风险,不管邮件内容写了什么。

如果交易类邮件和营销邮件还没有分开,就把它们分到各自独立的子域名上,并配上各自独立的签名密钥,把这件事当作基础设施工作来对待,而不是营销团队的一个决定,因为在这件事上出错,代价是身份验证失败,而不是一笔丢掉的生意。

按固定的时间表,通过服务商自己的报告或谷歌的 Postmaster Tools 观察真实的投诉率,把任何接近 0.10% 的迹象都当作该去调查的信号,而不是等到 0.30%,因为 0.30% 更接近邮件开始被拒收的那个点,而不是问题开始的那个点。再定期给一个私人的 Gmail 地址和一个私人的雅虎地址发一次真实的测试注册,计时看验证码用多久到达,又落在了哪里,因为一个报告发送成功的仪表盘,报告的是离开服务器的那一刻,不是用户真正看到的那一刻。