从旧身份开始，而不是猜测的SPF包括
名为“Roaring Penguins”的库存条目不足以配置发送者。该公司的历史名称是 Roaring Penguin Software，其产品包括多个 CanIt 变体。在编辑DNS之前，请确定组织实际使用的内容：已安装的设备或软件版本、托管服务、经销商管理的路由或迁移后留下的历史标签。本文提供了审核和证据工作流程，而不是经过验证的当前部署方案。
公司于 2010 年 11 月发布的版本描述了 CanIt-PRO、CanIt-Domain-PRO 和托管 CanIt。它宣布 DKIM 支持过滤上下文，包括在评估邮件时使用签名者信息。该历史声明并未建立现代客户域签名界面或 SPF 包括今天可以安全发布的内容。 Roaring Penguin 的 CanIt 7.0.8 公告
Marlin 于 2018 年 3 月宣布收购 Roaring Penguin，将其纳入 AppRiver 的电子邮件安全业务。获取历史记录有助于解释旧标签，但不能证明特定客户使用哪种后续服务、是否支持其旧安装，或者适用哪些DNS指令。 马林收购公告
本研究中并未建立当前提供商拥有的用于确切遗留部署的设置文档。缺乏经过验证的当前设置源并不能证明产品已退役。请勿将搜索片段、第三方镜像手册或收购公告转变为当前的生产说明。保持产品和源保持可见，直到部署所有者提供受支持的参考。
重建实际邮件路径
从系统所有者、服务协议、安装版本、管理端点和负责的支持组织开始。记录名称出现的位置：邮件清单、 SPF机制、 MX目标、收到的标头或计费记录。这些线索回答了不同的问题。入站路径中的过滤主机名并不能证明该服务源自组织的出站电子邮件。
在改签单中画出简单的路线清单。识别原始应用程序或邮箱、任何中继或过滤器、公共出口服务以及用于测试的目的地。将每个跃点标记为观察到的、记录的或仍然推断的。如果经销商管理服务，请要求其确定基础产品及其当前支持的确切范围，而无需假设客户拥有供应商的原始管理界面。
收集受控的出站消息，并单独收集了解过滤器所需的任何入站示例。使用无害的内容和授权的接收者。保留时间戳和相关路由标头，并最大限度地减少个人信息。不要假设带有产品名称的标头是可信的所有权证明；将其与组织配置的路线和接收者自己的观察结果相关联。
管理员可能会发现旧组件仅接收邮件，而出站流量则通过另一个提供商离开。在这种情况下，请将出站身份验证移至实际发送服务的指南。将旧组件保留在入站服务清单中，并且不要仅仅为了使每个清单条目显示为“已配置”而添加发送权限。
将签名验证与签名创建分开
入站DKIM验证询问收到的签名是否经过验证。出站签名为离开授权域的消息创建签名。为有效签名者提供较低垃圾邮件分数的过滤规则不会创建组织的签名。历史公告支持 DKIM 相关过滤功能的存在，而不是特定于帐户的签名过程。 咆哮企鹅的历史性DKIM公告
对于出站签名声明，需要签名系统、域、 选择器、公钥发布以及传递的接收到的签名。 DKIM的 sd= 和 s= 值标识查找中使用的签名域和选择器。在旧选择器下找到的DNS记录并不显示任何当前消息仍在使用它进行签名。 DKIM RFC 6376
向当前操作员询问与已安装版本和部署模型相匹配的支持说明。确定谁持有私钥以及如何管理轮换和恢复，而无需请求密钥本身。记录签名后下游系统是否修改消息。在任何批准的更改之前和之后进行测试，以便审阅者可以区分丢失的签名和稍后失效的签名。
不要仅根据旧手册发布新的选择器、替换公钥或切换签名控件。对于更改的服务或不受支持的安装，即使是历史上真实的过程也可能是错误的。安全的下一步是证据请求和范围测试计划，而不是猜测的菜单路径。
仅根据观察到的身份评估SPF和DMARC
确定出站邮件的SMTP信封域和公共出口路径。 SPF为评估的SMTP身份授权发送系统；它不会使入站过滤服务成为发件人。保留现有的合法授权，为每个所有者维护一项适用的SPF策略，并在提出任何替换之前评估查找限制。 SPF RFC 7208
这里不提供通用的咆哮企鹅。获取当前提供商的说明或管理员验证的确切路线的出口详细信息。不要仅仅因为某个域出现在存档示例中而重复使用该域。记录将每个提议的权限与活动邮件相关联的证据，包括可以确认的服务所有者。
然后将传递的SPF或DKIM域与可见的 From 域进行比较。 DMARC 需要通过对齐路径，而不仅仅是标头中某处存在旧产品名称或身份验证传递。申请 RFC 9989 并保存接收者的结果以及解释它的域。 DMARC RFC 9989
如果无法支持或验证该路由，请与邮件所有者一起计划受控迁移。首先盘点关键发件人，建立替换路线，验证 结盟 那里，和文件恢复。在检查剩余流量和依赖关系之前，请勿删除旧记录。
虚构诊断：入站过滤器被误认为是出站发件人
一个虚构的组织在其邮件文档中看到 Roaring Penguin 标签，并假设它必须添加新的SPF包含。调查员进行了出站测试，发现旧过滤器仅存在于入站邮件中。该消息实际上是通过单独管理的中继发出的。这个发明的场景说明了库存错误，而不是测量的咆哮企鹅部署。
该团队验证中继的信封和DKIM身份，并将其身份验证工作分配给中继所有者。它使入站过滤器的支持问题保持开放状态，但不会进行推测性SPF更改。在淘汰任何东西之前，第二次审查会检查旧的签名选择器是否仍在使用。结果是修正的路线清单和合理的变更计划，而不是由不必要的授权创建的绿色状态。
旧路由工作表
- 身份：历史标签、确切的产品、版本、部署模型、运营商和当前支持联系人。
- 方向：入站过滤、出站中继、签名或未解析；包括每个分类的证据。
- 路由：原始工作负载、中间系统、公共出口、时间戳和授权测试接收者。
- 身份验证：可见发件人、信封域、 DKIM d=/s=对、可信结果和对齐查找。
- 文档：当前提供程序参考、版本适用性、已发布的公共值和未解决的功能。
- 过渡：支持替换（如果需要）、关键发送者、回滚所有者和退役依赖项。
出版边界
这是一个完整的遗留审计候选者，具有明确的实施保留。目前尚未验证特定于提供商的SPF值、选择器或接口程序。实时部署、 DNS 、标头、视觉、人类 SME 和发布门仍然悬而未决。在出版之前，编辑必须决定已解决的证据是否支持设置指南，或者该主题是否应保留明确标记的遗留评估。
根据历史证据可以证实的内容来标记历史证据
2010年的发布建立了历史过滤功能，2018年的公告建立了收购历史。两者都无法建立有效的客户路线、当前的支持权利或后续签名配置。将这些记录为当前操作员的单独问题；不要将公司历史变成可执行的DNS配方。
将消息接受与策略推出分开
通过的对齐SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。