清点实际路径而不是应用程序标签
“使用SMTP ”不会告诉电子邮件团队如何允许应用程序发送。应用程序可以通过邮箱提交、通过组织的连接器转发或直接传送到收件人系统。这些路由具有不同的身份、权限和收件人限制。仅记录供应商名称和发件人地址的库存可能会错过使路线有效的条件。
为每个实质上不同的应用程序路径创建一个条目。捕获配置的端点、端口、传输要求、身份验证方法、 信封发件人，可见发件人地址、预期收件人和队列所有者。包括相关的托管位置和接收服务观察到的公共源 IP。计算机的私有地址并不是云连接器在网络转换后看到的地址的证据。
区分SMTP角色和提供商产品名称
SMTP中继是一般传输角色，而 Microsoft 的“ SMTP中继”和“直接发送”标记了特定记录的选项。在 2026 年 11 月 8 日审核的Microsoft 365应用程序设置指南中，客户端提交使用邮箱身份验证，中继使用入站连接器，并且直接发送到达云组织内部的收件人，而不是提供外部中继。这些标签不应不加批判地转移给其他提供商。 Microsoft 应用程序邮件设置.
在协议级别，客户端呈现SMTP事务并接收各个步骤的回复。成功的连接不会建立中继到每个目的地的权限。在对被拒绝的收件人进行故障排除之前，记录针对所选端点的接收角色。公共MX是入站目的地，而不是使用其所有者作为无限制传出服务的邀请。 RFC 5321 ，第 2.3 和 3.3 节.
将路线要求放在库存旁边
对于记录的 Microsoft 选择，记录smtp.office365.com用于客户端提交，记录租户MX端点用于中继或直接发送。中继资格取决于配置的证书或合格的公共 IP 连接器；邮箱认证属于提交路由。保留当前指南对托管、发件人域、传输和收件人范围的限制，而不是复制通用配置方案。微软的设置页面于2026年9月16日更新；租户的适用性仍需确认。 Microsoft 应用程序邮件设置.
需求路线图是一个文件清单框架。其目的是揭露缺失的证据，而不是自动选择路线。如果应用程序需要外部收件人，则即使内部测试成功，仅租户路径也是功能不匹配的。如果路由依赖于连接器，则未经过验证的连接器匹配的已保存主机名是不完整的证据。如果有意限制身份验证设置，请选择授权支持的设计，而不是禁用安全控制以使旧配方发挥作用。
保持发件人授权与身份验证结果不同
服务提交邮件的权限与消息的权限是分开的 SPF, DKIM 和 DMARC 下游接收器的结果。成功的邮箱身份验证并不能证明可见的发件人地址已获得该邮箱的授权。与源匹配的连接器并不证明每条生成的消息都具有一致的身份验证。相反，改变公共 SPF记录 不授予SMTP服务中继权限。
将管理权限和下游身份证据记录在单独的清单字段中。 DMARC根据经过身份验证的标识符评估作者域；它不是应用程序保存提交凭据的注册表。最终接收者的结果应与确切的消息和评估位置相关联。 RFC 9989 ，第 4.4 节。凭证和令牌绝不能出现在清单或诊断票中；相反，记录对其所有者和管理流程的批准参考。
使用虚构的应用程序来公开隐藏的依赖项
假设虚构的仓库扫描仪通过租户MX端点向员工发送调度通知。它的清单上写着“ SMTP中继”，但没有附上连接器证据。后来，团队添加了外部快递地址，但投递失败。该故障并不表明快递员的域或扫描仪的SPF有缺陷。第一个问题是该路由是否曾经被授权用于外部中继，或者成功的内部邮件是否使用了不同的服务路径。
第二个虚构的更改将扫描仪的流量移动到新的网络网关。应用程序设置保持不变，但服务看到的公共源发生了变化。如果批准的路线取决于该源身份，则未更改的应用程序屏幕会产生误导。在进行任何配置更改之前，请将授权连接器证据和实际网络路径与之前的工作记录进行比较。这两种情况都不是实时测试或帐户诊断。
计划受控验收测试
为每个所需的收件人类别选择一个授权收件人、一条无害的唯一标识消息以及一个负责操作员的时间窗口。记录完整的SMTP回复和阶段、队列标识符、路由以及最终可信身份验证结果（如果有）。提交接受响应证明是移交，而不是最终收件箱放置。在消息数据之后的肯定完成响应之后，下游服务器承担传输责任。 RFC 5321 ，第 4.2.5 节.
包括负面期望，而不探究不相关的接收者或公共中继。如果路由故意仅供内部使用，则要求记录该限制，而不是发现绕过它的方法。保持重试所有权明确，以便应用程序在其邮件服务已将第一条消息排队时不会创建第二条消息。
保持库存版本
在网络迁移、证书续订、身份验证策略更改或收件人范围扩展后查看条目。提供商文档是过时的证据，而实际的租户配置是单独的证据。不应通过共享密码或削弱安全措施来挽救已弃用的身份验证配方。
包含当前提供商证据和受控测试消息的需求路线图。这个确切的要求仍然开放。未检查或更改租户设置、连接器、凭据、网络路由或受控消息。提供的地图和示例为调查做好准备；他们不证明应用程序配置正确。