定义出站网关范围
本指南使用思科安全电子邮件云网关的 AsyncOS 16.0 常规部署文档，其电子邮件身份验证章节的日期为 2024 年 10 月 3 日。它是受版本限制的配置和验收计划，而不是有关最新版本或已检查租户的声明。记录的签名工作流程创建密钥、关联域配置文件、发布DNS验证材料并启用出站策略中的签名。所描述的 GUI 路径是“邮件策略”、“邮件流策略”、“RELAYED”，然后是“DomainKeys/ DKIM签名”，最后是“提交”和“提交”。传入验证与出站签名是分开的。配置文件不匹配可能会导致消息未签名。 思科电子邮件身份验证指南
该有界工作流程提供了一个架构起点。它不提供租户的 选择器、私钥、出站 IP 库存或已批准 SPF 授权。本文的其余部分是用于将记录的工作流程与协议证据连接起来的原始审查方法。在实施之前，负责的管理员必须确认实际的网关版本、支持的控件、更改权限和消息路由。此处尚未访问网关，也未创建密钥、策略或消息。
从路线合同开始
记下邮件的来源以及哪个系统进行最终的向外SMTP连接。包括任何应用程序中继、上游邮箱系统、网关、下游中继和面向收件人的出口。目的是找到必须评估签名和SPF授权的点，而不是收集每个内部网络地址。将敏感配置保留在组织的受控变更记录中，而不是将其嵌入广泛共享的文章中。
对于每个路由，记录预期的可见发件人域、 SMTP 邮件来自 域和预期 DKIM 签名域。即使组织故意使它们看起来相似，它们也是不同的身份。 SPF评估相关的SMTP身份和连接地址。 DKIM验证与其签名域关联的签名。 DMARC 将合格的经过身份验证的标识符与可见的作者域相关联。网关在路由中的存在本身并不是经过身份验证的身份。 RFC 7208 ，第 2.3–2.4 节 RFC 6376 ，第 3.5 节 RFC 9989 ，第 4.4 节
路由合同应包括例外情况：自动通知、委托发件人、具有异常标头的应用程序以及绕过预期网关的邮件。不要接受仅基于一条方便的员工消息的配置。确定哪些不同的路线需要证据，哪些路线明确位于部署之外。这会产生一个可审查的边界，而不是一个不受支持的声明，即所有公司电子邮件都经过身份验证。
将密钥发布与签署接受分开
DKIM部署至少有两个不同的职责。签名者保护并使用私钥，而DNS使相应的验证材料可被发现。签名提供了标识密钥位置的选择器和签名域。发布看似合理的TXT值并不能证明网关拥有匹配密钥或对预期路由进行签名。相反，启用签名并不证明公共记录可供接收者使用。 RFC 6376 ，第 3.5 节和3.6.2.2节
使用更改记录将批准的签名域、选择器、公钥指纹或等效的非秘密标识符、 DNS所有者和预期策略绑定到同一部署。切勿将私钥粘贴到工作表中。从支持的实施和组织安全策略中获取当前的加密和密钥管理要求，而不是从旧指南中复制历史最低要求。本手稿故意不提供可重用的密钥材料或密钥生成命令。
独立于编辑器显示查看确切的DNS所有者。相对选择器标签可以通过DNS接口扩展，而完整名称可能需要不同的处理。在发布之前保留预期的完全限定名称和逻辑TXT内容。一个字符串中包含多个字符串 TXT记录 与多个竞争资源记录不同。应在上下文中调查显示分割或引号，而不是自动将其视为损坏。 RFC 1035 ，第 3.3.14 和 5.1 节
检查真实出口边界的SPF
不要根据产品名称发明 Cisco 范围的SPF包含。相关授权取决于实际的出站基础设施和信封域。负责的运营商应获取当前批准的出口信息，将其与现有的合法发送者进行协调，并审查由此产生的完整策略。即使托管网关、上游邮箱平台和应用程序都由同一团队管理，也可以代表不同的授权需求。
SPF必须在适用的域下以TXT形式发布。多种适用 SPF记录 产生错误而不是合并到更大的允许列表中。评估预算还适用于递归评估的 DNS 查询术语，而不仅仅是顶级策略中可见的包含字符串的数量。在添加其他服务之前检查依赖性行为，并保留不会静默删除现有发件人的回滚计划。 RFC 7208 ，第 3.1–3.3 节和 4.6.4 节
提供商控制的信封域的通过SPF结果不一定与组织的可见发件人域一致。如果路由依赖于对齐的DKIM ，请明确保留该选择。 DMARC需要符合资格的SPF或DKIM结果，但项目或提供商可能会施加额外的先决条件。不要将协议的替代路径转变为忽略实现要求的权限。 RFC 9989 ，第 4.4 节
构建证据序列而不是成功的屏幕截图
提议的接受序列对于配置意图、发布的DNS和实际接收的消息有单独的检查点。首先，确认支持的租户配置与批准的路由合同匹配。其次，保留授权的DNS观察，包括所有者名称、类型、逻辑值和观察时间。第三，评估发送系统外部收到的已批准消息，记录相关标识符和身份验证结果，而无需发布私人信件。
当证据不一致时，在改变策略之前对层进行诊断。未签名的消息与无法找到验证密钥的签名消息是不同的问题。有效但未对齐的签名不同于因消息修改而无效的签名。来自旧缓存的DNS观察与不正确的权威记录不同。这些区别可以防止团队削弱DMARC以隐藏未解决的签名或路由问题。 DKIM验证和DMARC 结盟 是相关但单独的评估。 RFC 6376 ，第 3.5–3.6 节 RFC 9989 ，第 4.4 节
虚构诊断：计划中缺失的路线
在一家虚构的公司 North Quay Parts 中，消息传递团队正在准备普通信件的签名。帐户应用程序仍然使用不同的批准的中继路径。审阅者看到一条员工消息的成功结果，并建议将整个域标记为完整。此场景不代表任何实际的公司、测试或结果。
审查因范围不匹配而停止。申请途径将添加到清单中，记录其信封和作者身份，并分配其签名责任。团队并没有猜测应用程序会遍历相同的网关策略。它还避免了用单一服务示例替换SPF或仅仅为了获得绿色指示器而更改DMARC 。在每条范围内的路线都有适当的授权证据之前，验收仍处于等待状态。
空白部署验收工作表
- 网关产品、版本和适用文档日期：____。
- 配置所有者、 DNS所有者和发布审批者：____。
- 消息类别和最终出口的批准路线：____。
- 预期发件人、邮件发件人和DKIM签名域：____。
- 支持的策略/配置文件关联和未解决的异常：____。
- 选择器和公共验证记录参考，不包括秘密：____。
- 现有SPF发件人、提议的授权和依赖性审查：____。
- 拟定DNS所有者、当前权威证据及观察时间：____。
- 实际批准的接收消息证据和一致性评估：____。
- 回滚条件、未解决的差异和批准决定：____。
工作表未填写且未执行任何操作步骤。原始实施证据、人工审查、当前来源适用性、生产路线、视觉/可访问性检查和所有者发布仍然开放。身份验证接受仍然不能保证交付、消息安全或业务请求的合法性。 RFC 9989 ，第 2.4 节