确定 Harmony 发送路由
本指南介绍了 Poppulo 当前知识库中描述的 Poppulo Harmony 电子邮件路由。这并不是适用于所有带有 Poppulo 名称的产品的通用程序。采集DNS值前，先建立企业账号、子账号、预期From域、实际传递路径。通信团队成功的内部交付可能反映的是网关异常，而不是域身份验证。
Poppulo 描述帐户分配的服务器池，并通过支持或客户成功经理提供池特定的 IP 详细信息。它还将经过身份验证的SMTP记录为跨子帐户应用的企业设置选项。确定组织是否使用 Poppulo 服务器路由或其他SMTP路由；不要假设一个帐户的测试代表不同的企业配置。 Poppulo Harmony 许可名单和身份验证
将企业管理员分配给应用程序更改，将DNS管理员分配给公共记录，将邮件安全所有者分配给接收者测试。记录每个人都会批准的内容。在此DNS工作之外保留内部 IP 允许列表，除非它明确属于更改的一部分。扩展网关异常并不能替代查找签名丢失或未对齐的原因。
添加域并保留配置
波普洛的 DKIM 步骤使用企业设置 > 电子邮件域 > DKIM > 添加域。输入目标域，复制生成的记录类型、所有者和值，然后将它们发布到其DNS提供商。离开前保存企业设置：提供商警告未保存的生成配置已丢失。传播完成后，选择“验证”，然后再次“保存”；验证不会自动保存页面。 Poppulo DKIM配置
此保存要求应出现在更改记录中。保留应用程序状态后捕获域和生成的公共值，然后将它们与DNS进行比较。不要维护已放弃的未保存尝试的工作表，同时期望稍后尝试使用相同的记录。如果两个管理员同时工作，请在发布或删除任何内容之前就哪个保存的配置具有权威性达成一致。
待处理状态需要调查，而不是立即重新生成。确认所有者是在正确的区域中创建的，并且DNS接口没有两次附加域。将实际的公开答案与保留的应用程序值进行比较，包括记录类型和完整目标。 Poppulo 在其验证故障排除步骤中列出了这些检查和传播时间。 Poppulo DKIM验证故障排除
请勿从白名单语言推断SPF对齐
Harmony 技术概述指出支持客户域DKIM ，但其简短 SPF 描述不是精确的特定于帐户的信封规范。它向客户发送支持 DMARC 细节。获取所选路由的实际SMTP信封标识和支持的配置，而不是发明通用的 Poppulo SPF包含或自定义 Return-Path 环境。 Poppulo 身份验证概述
SPF为发送主机授权SMTP身份。 DKIM验证与其 d= 域和 s= 关联的签名 选择器。然后， DMARC将成功通过身份验证的域与可见的发件人域进行比较。 一个记录 当服务使用另一个信封域时，不一定会评估添加到企业根的情况。一传对齐 DKIM签名 即使另一个签名或未对齐的SPF路径不满足，也可以满足DMARC 。 SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989
如果真正的信息缺乏一致的路径，就停止在这个发现上。询问授权支持联系人哪个配置适用于企业、路由和发件人域。不要仅仅因为内部新闻通讯失败就削弱组织的DMARC策略或将整个共享 IP 池添加到SPF 。在建立正确的更改时保留当前记录。
在公司网关之外进行测试
通过相同的工作流程和来自用于生产的域使用无害的测试。如果获得授权，请在公司网关外部添加接收者，以便内部白名单不会掩盖结果。私下保留完整的技术标题并创建经过清理的身份表以供审查。成功的预览、链接点击或交付的内部副本不会在另一个接收者处证明一致的身份验证。
记录接收者的信任 Authentication-Results 旁边还有 From、 Return-Path 、每个DKIM d= 和 s= 值以及时间。根据配置的域和适用的情况检查实际签名域 结盟 模式。经过验证的应用程序状态是有用的设置证据，但以后不同的发件人地址或发送路由可能会更改结果。
对于多个子账户，确定哪些域和工作流程共享配置以及哪些需要单独的测试。当涉及经过身份验证的SMTP时，确定哪个系统对最终消息进行签名以及后续处理是否会更改签名内容。将其视为单独的路由评估，而不是断言 Poppulo 的域验证涵盖下游中继。
Poppulo企业验收工作表
这些是需要填写的字段，而不是已经收集的结果。
- 企业和路由：帐户所有者、子帐户、活动或通信工作流程、Populo 服务器池或经过身份验证的SMTP以及预期的发件人域。
- 保存的配置：生成的DNS值、首次保存时间、权威DNS所有者、发布的答案、验证结果和最终保存时间。
- 接收器覆盖范围：内部网关行为、适用的白名单范围、授权的外部测试接收器和消息时间戳。
- 身份比较：可见发件人、信封域、每个签名域和选择器、可信身份验证结果以及对齐的传递路径（如果存在）。
- 开放性问题：需要确认的特定于路由的SPF或反弹域支持、不受支持的产品假设以及缺少测试。
- 发布决策：证据所有者、恢复配置、业务审批、安全审查和编辑审查状态。
未保存验证的虚构诊断
这个场景是虚构的。内部通信管理员在设置过程中看到“已验证”并关闭该页面。一位同事后来发送了一个活动，安全团队在外部接收器上发现没有预期的对齐签名。内部收件人收到邮件是因为他们的网关允许分配的发送 IP 范围。
团队检查保留的企业配置，而不是将交付视为证据。它发现最后的保存步骤被省略了。建议的修复是恢复并保留预期的域配置，将DNS与保存的记录集进行比较，验证、保存并在外部重新测试原始工作流程。不假设任何结果：收到的签名域和接收器结果必须确定该修复是否解决了问题。
审查和发布门
已审查第一方文档，但未访问 Poppulo 企业、 DNS区域、网关策略、支持响应或实时消息。确切的产品范围、保存的应用值、支持确认的路线、收到的对齐证据以及 SME 人工签核仍然开放。该手稿尚未发表，需要进行演示审查。不要将整个 Poppulo 资产描述为通过单个域状态或内部传递的消息进行身份验证。
关闭路由检查点之前的配置检查点
为保留的生成值、公共DNS匹配、保留的验证和接收的对齐保留单独的条目。在虚构的情况下，缺少预期签名并不能证明每个签名都失败了；其余结果未明确。在诊断最终DMARC结果之前，重新测试必须确定所有通过的一致机制。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。