云邮件「没收到」，租户间邮件流排查应该按什么顺序查？

「没收到」的排查有且只有一个正确起点——用邮件追溯按发件人、收件人与时间范围检索，确认本租户是否有这封邮件的记录。

这一步把问题空间一刀切成两半，避免在错误的方向上浪费时间：

• 查得到记录：邮件已进入，问题在本侧的过滤、路由或投递环节。
• 查不到记录：邮件根本没到过本租户，本侧的所有策略都与此无关。

先去翻策略配置而不是先查追溯，是最常见的时间浪费。

确认查无记录后，按此顺序核对：

1. 收件地址是否拼对，是否为已启用的有效收件人。
2. 本域 MX 记录是否正确——若近期做过迁移或调整，邮件可能仍在投向旧的目标。
3. 要求发件方提供其退信内容。退信中的状态码与文字说明通常直接给出原因，远比在本侧盲猜高效。
4. 发件方若也是企业租户，请其提供自己一侧的出站追溯结果，确认邮件确实已发出以及投向了哪个目标。

• 已送达：平台已投进邮箱。接下来查收件箱规则、用户自建的转发或删除规则、垃圾邮件文件夹、以及客户端是否完成同步。「已送达但用户说没有」绝大多数是收件箱规则造成的，这一条值得优先怀疑。
• 已隔离：被安全策略拦下，去隔离区查看命中的具体策略。
• 已筛选为垃圾邮件：投进了垃圾邮件文件夹，属于判定偏严，走误报调优流程。
• 失败：投递被拒，记录中会带有拒绝原因。
• 已扩展：发往通讯组，需要按展开后的各个成员分别追溯。漏掉这一步会误以为邮件在此中断。

• 时间范围有上限，超过保留期的历史需要走报告导出，结果不是实时返回。涉及久远事件时要尽早发起。
• 结果条数有上限，检索条件过宽会被截断而看不到目标邮件。应尽量用收件人加时间窗缩小范围。
• 刚发生的邮件可能有短暂延迟才出现在结果中。刚发完就查不到，先等一会儿再查，不要立刻下结论。

需要对方配合排查时，来回沟通的成本很高。第一次就把这五项要全：

• 完整的发件人与收件人地址；
• 精确到分钟的发送时间及时区；
• 邮件的 Message-ID（这是跨组织唯一可靠的关联标识，主题和时间都可能重复或有偏差）；
• 对方一侧的出站追溯截图或导出；
• 若有退信，退信全文。

同一类问题反复出现时，应当把结论固化下来而不是每次重查：

• 某合作方持续因认证不合格被拦 ⇒ 推动对方修复，而不是每次手工放行。
• 某类业务邮件频繁进垃圾箱 ⇒ 检查其发送源的认证配置与内容特征。
• 某部门反复出现「已送达但没看到」⇒ 排查是否存在批量下发的收件箱规则或转发配置。