识别域发送的每种方式
Simply.com 可以托管邮箱、网站和DNS ，但这些角色并不能使使用该域的每个应用程序都遵循相同的邮件路径。从路由清单开始：网络邮件、配置的邮件客户端、网站联系表单、订单通知和任何外部服务。请注意应用程序在哪里运行、它提交到哪个服务器以及业务期望的可见发送者。
本指南涵盖 Simply.com 公共邮件文档中指定的路由。它不会将提供商的签名承诺扩展到不相关的新闻通讯平台、其他地方托管的服务器或使用其他传输的脚本。现有账户也需要检查；新托管计划的记录默认值并不能证明旧的或外部管理的区域具有相同的记录。
查看记录的记录而不覆盖区域
Simply.com 的身份验证指南 列出了 SPF 授权include:spf.simply.com和两个 DKIM CNAME：simplycom1。 _domainkey为dkim1.simply.com和 simplecom2。 _domainkey到dkim2.simply.com 。其SPF示例假设邮件仅通过 Simply.com 发送。它将端口 587 上的 webmail、 websmtp.simply.com和smtp.simply.com命名为签名路由。
将这些视为记录的公共值，而不是您域中观察到的记录。在进行授权更改之前导出当前区域。识别权威DNS提供商并确认其接口期望的所有者格式。如果它自动附加域，请防止后缀重复。将发布的结果与所需的完全限定名称进行比较，而不是依赖于表单的视觉外观。
对于SPF ，在更改策略之前清点其他合法服务。 RFC 7208 描述单一策略选择规则和 DNS查找限制。查看组合评估，包括嵌套包含，而不是仅计算顶层可见的术语。保留现有的服务权限，除非其所有者已确认停用。
让网站邮件使用预期的传输方式
这 脚本邮件指南 描述了在端口 587 上向websmtp.simply.com进行身份验证的提交，其中 STARTTLS 支持 Simply.com 网络服务器上的脚本。它将该路由与 PHP mail() 区分开来，并限制该服务用作一般客户端或外部托管中继。它还警告不要将其视为大容量散装平台。
检查正在运行的应用程序实际上做了什么。邮件插件可以安装但被禁用、被另一个插件覆盖或被特定表单绕过。记录应用、有效的运输和负责的维护人员。成功的密码重置通知不一定会验证通过不同库发送的商务扩展。
使用组织批准的凭证管理流程进行任何后续配置。请勿将密码放入工作表、 DNS 、屏幕截图或支持示例中。此草案不会登录、安装插件、更改应用程序设置或传输凭据。
将托管DMARC政策作为单独的决策进行审核
Simply.com 记录了默认的_dmarc CNAME 访问dmarc.simply.com并将拒绝描述为其标准策略。在决定组织是否应该保留提供商管理的策略或管理自己的策略之前，请检查当前所有者及其有效答案。外部托管区域可能有所不同，现有的自定义策略可能包括报告或 结盟 设置业务需求。
不要添加 TXT记录 位于同一所有者的现有CNAME旁边。如果批准的更改替换了别名，请记录旧答案、预期的新策略、报告目的地和恢复过程。在将报告传输到新目的地之前，请确认报告收件人和任何所需的授权。这是域策略工作，而不是检查两个签名记录的必然副作用。
DKIM通过签名域来验证责任，而不是单个人类作者的身份或权限。提供者的解释有时会将政策和交付压缩为简单的承诺。使用 RFC 9989 对于协议解释：对齐很重要，接收器处理并不能保证每个合法消息都到达收件箱或每个 网络钓鱼 消息消失。将身份验证接受和收件人放置作为单独的措施。
验证两个选择器和活动签名
一个提供商可以发布多个 选择器 出于运营原因。确认两个记录的 CNAME 按预期存在，而不假设特定消息必须使用哪一个。从受控接收的消息中，捕获每个DKIM签名域和选择器。 RFC 6376 定义这些字段如何识别验证密钥。
如果签名失败，则将DNS解析、意外签名身份和消息修改分开。如果没有出现预期的签名，请在更换密钥之前调查提交路径。使用非预期传输的表单不会仅仅因为域具有有效的 CNAME 而成为记录的签名路径。
捕获 信封发件人 以及。经过审查的 Simply.com 来源并未建立通用的用户可配置自定义 Return-Path 特征。不要从邮箱地址或回复目的地推断。记录观察到的身份和提供对齐的机制。
将转发的消息保留在不同的测试组中
Simply.com 的 转发指南 警告外部转发可能不可靠，因为转发路径可能会影响SPF或DKIM 。因此，转发的消息不能用作原始出站路由的唯一测试。
首先测试从网络邮件和应用程序路径的直接传递。如果转发是业务需求，请将其添加为单独的行，其中包含原始接收者观察结果和最终接收者观察结果。调查相关签名是否存在以及最终接收者评估的身份。不要仅仅因为稍后的转发更改了发送服务器而扩大原始发件人的SPF权限。
使用路线覆盖范围工作表
Simply.com 邮箱和网站工作表（使用此处描述的字段创建单独的审核记录）包括每个传输的一行、有效的DNS策略、当前签名选择器和最终接收器结果。使用DNS证据保留受控的消息标识符和观察时间。为每个应用程序记录单独的结果，而不是在一个样本后写“网站邮件已通过”。
当业务所有者识别发件人和回复行为时，路由已准备好接受批准，邮件管理员可以识别一致的传递机制，并且恢复所有者可以解释如何反转特定更改。未观察到的字段仍待处理。
涉及联系表的虚构诊断案例
仅虚构的书面案例：SCOM-01 规定网络邮件来自help@repair.example ，并传递d=repair.example.联系表单具有相同的 From，但运行 PHP mail()，而不是记录的经过身份验证的脚本提交路径；其DKIM和SPF结果未知。应用程序维护者必须检查有效传输，提出支持的修正并单独测试表单。订单通知仍然是第三个未经测试的途径。未访问任何应用程序设置、凭据、 DNS或消息。
恢复并维护特定路线的证据
在推出之前，保留以前的DNS和应用程序设置并同意谁可以恢复它们。如果更改后的表单丢失了邮件，请暂停该应用程序更改，而不是削弱每个发件人的域策略。当现有消息或另一个配置的路由可能仍在使用选择器时，请避免删除该选择器。
在托管移动、邮件插件更改、 SMTP更改、新的外部发件人和 DMARC 策略更改后重新测试。这是一份未发表的纪录片草稿。帐户检查、实时DNS 、收到的消息证据、原始范围验收、目视审查和 SME 人工签核仍然悬而未决。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。