将发送权限与身份验证分开
ReachMail 有两个不同的域检查。 发送域验证 确认在活动中使用地址域的权限。域身份验证将出站邮件连接到基于 DNS 的证据。完成通过电子邮件发送的验证链接并不能证明后续活动将带有一致的 SPF 或者 DKIM 身份。
在更改设置之前选择拥有的域和预期的发件人地址。 ReachMail 的验证指南不包括用于此用途的免费网络邮件域，例如Gmail 、 Yahoo和AOL 。记录各品牌负责人、回复邮箱及账号。将不同的客户或品牌领域分开，而不是假设一项批准延伸到其他领域。
这 入门清单 说默认DKIM 、 SPF和跟踪使用 ReachMail 管理的共享域。这解释了为什么基本身份验证可能已经存在而无需证明 结盟 到组织的可见发件人。接受目标是使用预期客户身份的受控消息，而不仅仅是平台签署其邮件的声明。
验证活动域
记录的验证路径是帐户、营销活动设置、发送域。验证电子邮件将发送到所选域中的地址，其确认链接将完成该步骤。使用组织控制的邮箱并记录审批结果。如果邮件丢失，请调查是否已发送到该邮箱，而不是重复添加新域。
到达邮件的 验证说明 还描述了一个挂锁，指示是否 DMARC 检测到策略。将其视为政策存在指标。它不是收到的消息结果，不是对每个授权发件人的评估，也不是活动的经过身份验证的域一致的证明。
检查要测试的邮件上的实际发件人和回复地址。保存的默认值和在现有活动中选择的身份可能有所不同，因此在发送之前请验证最终对象。在撤销活动活动使用的域之前获得批准。清理不应意外删除计划业务消息所需的发送身份。
生成正确域的身份验证指令
这 DKIM安装指南 将管理员引导至“帐户”选项卡、“活动设置”和“域身份验证”，然后添加域和适用的子域。其设置页面提供SPF 、 DKIM和DMARC说明。捕获为所选帐户和域发出的确切值。
创建一个DNS更改表，列出每个完整的所有者、记录类型、值和用途。确认DNS编辑器需要短标签还是完整域名。保留这些所有者的现有记录并在更换之前解决冲突。公共指南解释了工作流程；它不提供复制到每个客户区域的通用密钥。
DKIM指令标识要发布的记录和 TXT 密钥数据，然后检查当前DNS 。 ReachMail 建议至少等待十分钟再重新检查。将此视为提供商的最低指导，而不是所有缓存或应用程序检查将在固定期限内更新的承诺。在重复更改之前，请比较权威答案、相关 TTL 和预期值。
仔细合并SPF并保留DMARC所有权
到达邮件的 SPF指数说明 显示现有记录和所需的添加，并警告不要删除现有授权。将此解释为更新目标所有者的一个SPF策略，而不是创建另一个单独的SPF策略。保留仍需要发送的合法服务。
RFC 7208 定义 SPF记录 评估期间 DNS 查询机制和修饰符的选择和十项限制。检查嵌套包含和重定向，而不仅仅是可见包含术语的数量。如果提议的组合策略超出限制或具有不明确的依赖性，请在推出之前解决该设计。
SPF根据SMTP身份进行评估，通常是 邮件来自 域，而不仅仅是可见的发件人地址。仅添加根域并不能证明 ReachMail 使用一致的客户信封。审核后的设置页面不会建立您帐户的自定义信封行为；保持该声明悬而未决，直到当前提供商的指示和真实的标头确认为止。
检查现有的 DMARC记录 在应用建议值之前。保留其批准的政策、调整模式和报告目的地。活动设置向导不应默默地替换域中所有发件人共享的安全决策。对执行的任何更改都需要域所有者的审查以及来自其他合法途径的证据。
测试实际发送的营销活动
发布后记录域身份验证状态和公共DNS答案。然后将无害的活动发送到一个小的受控列表。验证营销活动是否使用预期的“发件人”而不是旧的默认值。如果员工公告是路线的一部分，则将内部收件人作为单独的案例包括在内。
保存消息 ID、UTC 时间、发件人、 Return-Path、所有DKIM签名域和选择器以及可信接收系统结果。 RFC 6376 定义DKIM d= 和 s= 标识符。检查每个签名：传递的共享域签名可能与客户域签名共存，而后者需要自己的结果。
DMARC的当前规范 需要一致的传递SPF或DKIM身份。记录哪个观察到的机制提供了路径以及应用了哪种对齐模式。即使信封仍属于提供商所有，客户域DKIM通行证也可以建立DMARC ，但仍需要满足提供商设置要求。
分别记录身份验证和放置。尽管有对齐的传递，但仍可能会传递到垃圾邮件，并且由于本地异常而接受的消息可能会隐藏未经验证的路由。如果没有副本到达，请在更改DNS之前关联营销活动和退回信息。重复完整的受众发送并不是适当的诊断测试。
ReachMail 接受工作表
每个活动域和相关发送路由完成一行：
- 帐户、品牌、企业主和预期发件人：____。
- 发送域名验证邮箱及完成时间：____。
- 活动身份和回复地址已检查：____。
- 帐户发出的SPF 、 DKIM和DMARC说明：____。
- 完整的DNS所有者、值引用和现有冲突：____。
- 结合SPF政策审查和保留的DMARC政策：____。
- 公共DNS答案并检查当前DNS结果：____。
- 消息 ID、UTC 时间、 Return-Path和所有DKIM标识符：____。
- 可信认证结果和实际一致机制：____。
- 恢复行动、发布审核者和未来重新检查触发因素：____。
已验证的域或闭合的挂锁无法填充消息证据字段。将路线保留为待处理状态，直到收到并检查了预期的活动。
误导性绿色指标的虚构诊断
仅虚构示例：Maple Studio 验证其发送域并看到关闭的挂锁。该团队假设自定义身份验证已完成。受控活动仅显示共享签名域和未对齐的信封，因此DMARC对于工作室的可见发件人失败。
管理员打开域身份验证，检索帐户发出的客户DKIM指令并完成批准的DNS更改。在更广泛的发送恢复之前，会检查新活动的实际签名域和一致结果。现有DMARC政策仍然有效。未检查 Maple 帐户、域名或消息；这是批准、策略存在和消息认证之间的说明性区别。
维护批准的域名库存
发件人域更改、 DNS移动、帐户迁移或密钥更换后重新检查。在停用经过验证的身份或委托记录之前，请检查计划的活动。实时租户检查、帐户特定值、 DNS和收到的消息证据、自定义信封确认、目视审查、SME 人工批准和发布仍有待完成。本指南涉及 ReachMail 营销活动；单独的继电器产品需要有自己的最新说明和测试。
记录检查了哪个绿色指示器
使用单独的工作表字段进行通过电子邮件发送的域批准、检测到的DMARC策略、 DNS身份验证状态和收到的活动对齐。在最后一项旁边记录活动标识符。虚构的例子没有规定对齐的传递机制；它并不能证明未对齐的信封总是会导致DMARC失败，因为对齐的DKIM仍然可以提供通行证。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。