[ 寄送服务指南 ]

配置 Trellix Email Security Cloud 自定义DKIM策略

为 Trellix Email Security Cloud 配置自定义签名,在发布TXT记录之前验证生成的密钥并解决记录的主机名歧义。

由EmailAuth研究团队提供 · 4 分钟阅读

[ 要点 ]

  • 为 Trellix Email Security Cloud 配置自定义签名,在发布TXT记录之前验证生成的密钥并解决记录的主机名歧义。
  • 有效密钥仍然需要预期的出站域策略关联。
在此页面上

范围和先决条件

Trellix 是一个作品集,而不是一个电子邮件路径。本指南涵盖电子邮件安全云自定义 DKIM Trellix 记录的政策。它没有为设备或其他产品建立等效步骤。确认出站邮件遍历此服务,识别其域策略所有者并导出现有签名记录。当前租户特定的出站 SPF 必须单独获取说明;此处未断言包含通用SPF 。

配置出站DKIM策略

在配置 > 策略下,创建出站DKIM策略。管理DKIM配置并生成密钥。发布帐户提供的 CNAME 目标或公钥TXT数据,然后验证主密钥和辅助密钥。将策略关联到域或域组的出站策略下并保存。自定义签名补充了 Trellix 的标准签名。美国政府租户缺乏主机名复制并使用TXT发布。源的TXT示例省略了CNAME示例中使用的下划线;在继续之前,请通过租户输出或支持解决完整的TXT所有者问题。请参阅下面的自定义DKIM策略。

独创双签名验收设计

使用外部测试消息枚举每个签名,而不仅仅是第一个 DKIM-Signature 标头。独立记录d=, s= 和接收器结果。如果传递的提供商签名的签名域与您可见的发件人不一致,则传递的提供商签名是不够的。失败的不相关签名不会否定另一个对齐的通过签名。接收者的 DMARC 结果及其评估的身份是验收证据。

对于虚构的可见 From alerts.example.org ,想象一个签名来自不相关的服务域,另一个签名来自alerts.example.org 。只有第二个可以提供准确的 结盟。这是一个发明的推理样本,而不是 Trellix 标头输出。该工作表故意将实际选择器、域和结果留空。

轮换前计划关键维护

记录其中 选择器 是活动的,哪个是备用的,谁可以重新生成它以及DNS是委托的还是手动管理的。手动TXT发布会创建单独的DNS更新依赖项:发布替换公钥后,在使用相应的签名者之前对其进行验证。不要在票证或工作表中公开私钥材料。

有用的失败测试是其密钥有效但未附加到预期域的策略。捕获来自该确切域的关联和消息,以区分DNS准备情况和策略应用。避免将相邻域的成功测试视为整个域组的证据。在恢复期间,恢复之前与邮件所有者验证的关联或签名状态;不要删除这两个键作为诊断快捷方式。

在接收方证明身份

使用受控的外部邮箱并通过生产工作流程发送,内容无害且无客户数据。保存原始消息、时间戳和接收系统的 Authentication-Results。忽略由不受信任的发件人插入的身份验证断言。记录可见的From域, Return-Path 或经过身份验证的信封身份,以及每个DKIM d= 和 s= 对。显示名称或回复地址不是DMARC身份。

SPF pass 授权连接服务器使用评估后的信封身份。 DKIM通行证验证其签名域的签名。 DMARC需要一个其域与可见From对齐的传递方法:严格对齐需要相同的域;宽松的对齐允许适用的组织域关系。提供商拥有的签名可以通过,无需验证您的可见发件人。即使另一个签名失败,一个通过的对齐DKIM签名也可以满足DMARC 。这些协议规则来自RFC 7208 、 RFC 6376和 RFC 9989,如下所列。

在诊断缓存之前检查权威DNS 。向权威服务器询问确切的名称和类型,然后在其缓存生命周期后比较递归解析器。对于DKIM ,请遵循任何CNAME到其公钥TXT响应。切勿发布私钥。对每个评估的名称保留一项SPF策略,并检查嵌套包含中的十个 DNS 查找导致术语限制。不要用提供商示例替换共享SPF策略。

恢复与验收

如果测试显示新的回归,请暂停受影响的工作流程。将更改的记录与保存的版本进行比较,并在检查其他发件人后仅撤消该更改。重新检查DNS并恢复后重新发送;恢复值不会立即刷新每个解析器。保持旧的DKIM验证记录可用,同时先前签名的邮件可能仍在传输中,除非安全事件需要撤销。

仅当DNS 、应用程序状态和实际收到的消息一致时才接受更改。记录流程所有者、证据时间戳和下一次审核触发器。收件箱放置本身并不能证明身份验证,并且成功的身份验证并不能保证收件箱放置。不要根据一个提供商的测试来收紧共享域的DMARC策略。首先盘点其他合法来源。

在轮换密钥之前找到丢失的关联

书面案例 TR-01 假定两个生成的选择器都显示example.org已验证,但预期的出站域与新的自定义DKIM策略没有关联。收到的教学样本来自alerts@example.org ,并且只有不相关的提供商域签名; SPF和任何其他签名仍然未知。邮件策略所有者应检查域的出站关联及其实际路由,而不是重新生成两个密钥。该部分样本无法得出完整的DMARC结果。标识符是说明性的,并且没有使用租户、密钥生成操作、策略更改或消息。

保留执行边界

RFC 9989第 7.4 节要求有效的DKIM ,而不仅仅是SPF来进行域发布 p=reject,并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护,同时诊断实际差距;任何政策变化都需要自己的决定。

[ 外卖 ]

有效密钥仍然需要预期的出站域策略关联。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

IT/邮件管理员

捕获实际标识符

捕获每个签名和确切的域策略关联,而不仅仅是密钥验证图标。

后续步骤

  1. 编辑前导出当前记录。
  2. 将收到的标头与计划的身份进行比较。
  3. 保留验证结果及其时间戳。

CISO / SecOps

审查委托发送信任

DNS委托和签名密钥是与所有者和停用日期的安全依赖性。

后续步骤

  1. 仅批准所需的发送范围。
  2. 将不相关的发件人保留在DMARC库存中。
  3. 检查依赖关系后删除陈旧的信任。

创始人/非技术人员

保护业务工作流程

分配 Trellix Email Security Cloud 的发布决策;保存的DNS记录不是已完成的邮件测试。

后续步骤

  1. 指定发送工作流程的所有者。
  2. 在广泛使用之前安排受控测试。
  3. 与服务所有者保留回滚决定。

[ 常见问题解答 ]

常见问题

这涵盖了哪些 Trellix 产品?

Email Security Cloud 自定义DKIM策略。其他部署需要自己的当前指令。

两个有效密钥是主动签名的证明吗?

否。检查域策略关联和来自该域的真实消息。

标准 Trellix 签名能否单独证明一致性?

仅当其实际签名身份一致时。仅有密码通行证是不够的。

我们应该从公共示例中复制哪个TXT主机名?

两个模棱两可的例子都不应该被猜测。在发布之前从租户输出或支持中确认完整所有者。

本文是否提供出站SPF包括?

不需要。获取您的租户和地区的最新说明,然后检查实际的信封身份。

美国政府租户应如何处理DNS步骤?

遵循受支持的租户特定TXT程序并确认确切的所有者和公钥。

我们可以在仅检查主选择器后进行轮换吗?

首先规划并验证备用密钥和任何DNS更新;保留已知良好的恢复路径。

这里是否捕获了双重签名的 Trellix 消息?

不会。该工作表是原始测试设计,没有观察到提供程序标头。

[ 来源 ]

来源

  1. 自定义DKIM策略

    部分 创建DKIM策略 · 更新DNS记录 · 验证DKIM密钥 · 将策略关联到域或域组 · 重新生成DKIM密钥 · 轮换DKIM密钥

  2. RFC 7208: SPF

    部分 §2.4 · §2.6.5 · §3.2 · §3.3 · §4.6.4

  3. RFC 6376: DKIM

    部分 §3.4 · §3.5 · §3.6 · §3.7 · §6.1 · §6.3

  4. RFC 9989: DMARC

    部分 §4.4 · §5.3.5 · §5.4 · §7.4 · §8

[ 词汇表 ]

词汇表

结盟
经过身份验证的标识符与可见的 From 域之间的域关系。
选择器
s= 值,用于在签名域下定位DKIM公钥。
信封发送者
SMTP MAIL FROM 身份,通常反映在投递后的Return-Path中。
权威DNS
发布区域数据的服务器,与缓存的递归答案不同。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库