出海踩坑实录：客服邮箱迁到飞书，工单系统消息断了
把客服邮箱从 Cloudflare 转发换成飞书公共邮箱，本来以为只是换个收件入口，结果把工单系统的邮件自动化整条切断了。这篇记录排查过程和修复方案。
把客服邮箱从 Cloudflare 转发换成飞书公共邮箱，本来以为只是换个收件入口，结果把工单系统的邮件自动化整条切断了。这篇记录排查过程和修复方案。
事情经过
先交代下原来的架构。
客服邮箱的域名 MX 指向 Cloudflare，Email Routing 收到邮件后交给一个 Email Worker，Worker 解析邮件、签名后推给自建工单系统的 webhook。
客户发邮件、回邮件，都会自动变成工单或追加到原来的工单线程里。
后来想让团队在飞书里共享处理客服邮件，就把这个地址迁成了飞书企业邮箱的公共邮箱，MX 也跟着指向了飞书。
但是发现不对劲。邮箱能收到客户邮件，工单系统里时有时无。
最迷惑的是时好时坏
彻底断流反而好查，时有时无的现象会把人往偶发 bug 的方向带。
实际上这和 bug 没关系。MX 改掉之后，收信路由从那一刻起指向飞书，但全网的 DNS 缓存不会同时过期。
缓存没过期的发件方，邮件照旧投给 Cloudflare，这部分正常进工单。拿到新 MX 的发件方，邮件直接投飞书，这部分就是遗漏。
同一个邮箱地址，两套系统各收一半。
等缓存全部过期，所有邮件只进飞书，自动化彻底断掉，而且全程不会有任何报错。
换托管过渡期的双路分流
排查三步
第一步，dig 看 MX 记录，发现已经指向飞书的邮件服务器。大方向基本确定。
第二步，查工单系统的入站日志。我们给每封入站邮件都落一条日志，不管是建单成功还是被拒收。
按小时聚合一拉，断点非常清楚。之前每天稳定进单，某个下午之后彻底静默，断点时间和改 MX 的时间对得上。
第三步，发探针实锤。用发信服务往客服邮箱发一封测试邮件，发信方显示投递成功，入站日志里却没有这封信。它进了飞书，链路断裂坐实。
入站日志表是当初做邮件入工单时顺手加的，每封邮件留痕。这次按时间轴一拉就看到断点，省了大量瞎猜。
根因是 MX 的排他性
一个域名的收信路由只能指向一家服务商，不存在让 Cloudflare 和飞书同时收信的配置。
换邮箱托管商等于把收信入口整个搬走。原来挂在旧入口上的所有自动化，工单、CRM、自动回复、转发规则，会同时静默失效。
还有一点容易混淆，收和发是两条独立的路。
我们外发邮件走的是发信服务的专用子域，SPF 和 DKIM 都配在子域上，所以这次只断了收，外发完全没受影响。排查时先确认这一点，范围一下就小了一半。
让飞书把邮件加投一份回来
最终方案是让飞书收到信后，自动给工单系统再投一份副本。
Cloudflare 这边，给域名开一个收信子域。Email Routing 从 2023 年起支持子域收信，免费套餐就能用，控制台添加子域后 MX 和 SPF 记录自动创建。
在子域上建一个专门的地址，路由动作直接指向原来那个 Email Worker。Worker 和工单系统的代码一行不用改。
Cloudflare Email Routing 子域功能官方文档
飞书这边用管理后台的"邮件流规则"，应用范围选公共邮箱，执行动作选"添加更多收件人"，把子域地址填进去。
比起给邮箱单独设自动转发，这个功能干净不少。不需要验证目标邮箱，转发时信头原样保留，公共邮箱自己也照常收信留档。入口在管理后台的产品设置、邮箱、安全与反垃圾里。
有一点要留意，邮件流规则是商业版功能，基础版没有。基础版可以退回每个邮箱单独设的"自动转发"，效果类似，只是要先给目标邮箱过一道验证。
飞书邮件流规则官方帮助文档
修好之后的链路是这样，客户邮件先到飞书公共邮箱，邮件流规则同时加投一份到 Cloudflare 子域，再走原来的 Worker 进工单系统。
团队在飞书看邮件，工单照常自动建，两边都有。
修复后的链路
验证还是用探针。先直发子域地址，确认 Cloudflare 这条腿通，再发客服邮箱，确认飞书转发的全链路通。第二封从发出到工单建立用了 46 秒。