使用帐户配置作为起点
Sendloop 提供了用于发件人域身份验证的帐户工作流程，而其公共身份验证向导还提到了专用的 DKIM 和 结盟 设置。这些页面确定身份验证可用，但它们没有为特定帐户建立确切的记录集、签名身份或信封控制。本指南将引导您完成记录的帐户工作流程和受控验证计划。专用DKIM安排或定制信封要求仍然是提供商确认项目。 Sendloop 身份验证向导、 DKIM和域对齐设置.
首先确定帐户、批准域以及使用每个帐户的活动或自动化。记录该账户是否有专门的送货安排以及谁可以确认。请勿从定价标签、旧的入职电子邮件或第三方发送 IP 列表推断专用基础设施。为组织分配一名 Sendloop 管理员、一名DNS所有者和一名审阅者 DMARC 政策。
在进行更改之前，请导出相关所有者的当前DNS条目。保留一名代表从现有批准的路线收到的消息（如果有）。现有工作的清单可以防止新的身份验证项目意外禁用另一个发件人。目标是经过身份验证和对齐的 Sendloop 路由，而不是域电子邮件配置的大规模替换。
打开发件人域控制面板
提供商的指南将引导您完成“设置”>“发件人域身份验证”>“验证发件人域”，然后“添加域”。生成的域控制面板提供帐户相关值和检查DNS记录操作。在编辑DNS之前捕获该输出。如果当前界面不同，请使用当前提供商说明或支持，而不是猜测等效按钮。 Sendloop 指南，使用电子邮件授权向导并检查您的身份验证设置.
记录每个完整所有者、 DNS类型、值和 TTL 及其用途。将显示的记录集附加到变更单上。如果面板显示缺失记录，请确定该记录是否不存在、由错误的所有者发布或以不同的值显示。已为另一个 Sendloop 帐户配置的域可能需要提供商协调而不是替换。
公共指南有一个 SPF 示例和现有记录修正案未列出相同的内容。它还描述了准备文本文件。不要将任何一个细节变成自动生产配方。 DNS必须包含当前适用的策略；保存在工作站上的文本文件不会发布。在实施之前解决帐户面板和公共页面之间的任何差异。 Sendloop 指南，设置SPF记录.
在不扩大不相关权限的情况下审查SPF
确定真正的 Sendloop 消息使用哪个信封域。这是要调查SPF的身份，而不是假设可见的 From 域必须是评估所有者。如果存在授权的自定义信封排列，请捕获其已发布的设置和范围。如果不存在，请记录观察到的提供商信封身份并单独评估DKIM对齐情况。
在任何所有者发生更改时，保留单个SPF策略并保留其他活动发件人所需的授权。添加新术语之前检查嵌套DNS查找。 SPF的十个术语限制适用于在评估期间导致DNS查找的机制和修饰符，而不是记录中可见的单词数。现有的许可机制也值得审查，但删除它们是一个单独的依赖决策。 RFC 7208 ，第 4.5 节和 4.6.4 节.
请勿复制广泛的样本政策来替代现有记录。这样做可能会授权不需要的主机、更改故障限定符或删除另一个提供程序。当所需的授权无法安全地满足时，请停止并要求邮件所有者选择支持的设计。不要通过发布另一个SPF策略或删除不熟悉的服务来解决问题。
仅发布已发布的公共DKIM材料
使用为此帐户提供的所有者和公共值。公共指南显示了DKIM TXT设置，但其演示密钥不是客户的密钥。如果专家组或支持人员提供了不同的支持记录表格，请保留该指示，而不是在没有证据的情况下转换它。 Sendloop 指南，设置DKIM记录.
只有公共验证密钥属于DNS 。 DKIM使用私钥创建加密签名；它不会将私钥嵌入到传出消息中。公共指南的非正式解释不应被解读为共享签名秘密的请求。消息携带签名，验证者使用其签名域标识的公钥和 选择器. RFC 6376 ，第 3.5 和 6.1 节.
检查提议的所有者是否有属于另一条路线的活动密钥。碰撞需要协调；仅仅为了清除红色状态而覆盖工作选择器是不安全的。发布后验证完全限定名称，包括DNS编辑器添加的域后缀。保留时间戳和查询结果，以便以后的报告可以将过时的缓存与不正确的所有者或密钥区分开来。
将链接品牌保留在联盟结论之外
提供商的指南描述了一个可选的 CNAME 用于别名消息链接。其目的是链接品牌，而不是SPF或DKIM一致的证据。仅当相关跟踪更改获得批准并且账户提供准确目标时才实施。 Sendloop 指南，可选：设置CNAME记录.
在声明提议的所有者之前，请检查现有网站或跟踪使用情况。不要将根网站或实时应用程序主机名指向跟踪目标。在受控活动中保留无害的测试链接，以便审核者可以验证其目的地及其显示的主机名。验证和链接功能是单独的验收检查；有效的品牌链接不会建立有效的签名。
发布后返回帐户的DNS检查。将每个显示的结果与独立的公共查找进行比较。诚实地记录未决状态。如果帐户显示已验证，但外部测试仍然失败，请保持更改打开状态并使用消息证据来定位剩余边界。
收集收到的消息身份记录
不使用客户数据，通过实际营销活动工作流程发送到受控外部邮箱。对于实质上不同的发件人域或交付配置重复此操作。保留原始消息和可信接收者结果，以及消息 ID 和 UTC 时间戳。记录所有DKIM签名，而不是在第一个通过的签名处停止。
证据记录应包含可见的发件人域、经过身份验证的信封身份、 Return-Path、 DKIM d= 和 s= 值、 SPF和DKIM结果以及接收者的DMARC结果。建立与 From 域一致的传递机制。宽松和严格的对齐强加了不同的领域比较；记录使用的模式。 RFC 9989 ，标识符对齐解释.
如果唯一传递的签名使用不相关的提供商域，请请求支持的客户域签名选项及其激活条件。公共向导的专用 DKIM 联系说明并不能证明该选项已启用、免费、在每个计划上可用或自动配置。获取确切帐户的答案。不要将跟踪别名表示为替代信封域。
使用失败来选择下一次检查
对于一个失踪的 DKIM签名，确认帐户，选择从身份和提供商激活。对于签名失败，请在调查签名内容的下游更改之前比较观察到的选择器和公钥。使用不同发件人地址的测试可能会成功，但受影响的活动仍然失败，因此在诊断期间保持工作流程不变。
对于SPF失败，请确定评估的域和最终发送源。对于SPF通过但DMARC失败的情况，请检查对齐情况，而不是添加更多SPF包含内容。如果提供商无法记录所需的身份选项，请阻止该要求，并与企业主一起评估其他支持的途径。不要仅仅为了使一个提供商的测试停止失败而降低整个域的策略。
准备一个支持包，其中包含帐户标识、受影响的域、发布的公共记录、观察到的DNS答案、消息 ID、时间和相关接收者结果。排除密码、API 密钥、收件人列表和不相关的消息内容。简洁的可重现故障比多个不相关的DNS编辑屏幕截图更有用。
工作表回收和验收
使用 Sendloop 身份验证工作表（使用此处描述的字段创建单独的审核记录）来跟踪记录差异审核、专用功能确认和最终身份比较。即使普通对齐的DKIM工作，丢失的信封功能答案也可能仍然无法明确解决。根据业务需求定义接受度，而不是用假设来填补每个空白。
如果更改失败，暂停受影响的发送并通过记录的更改计划恢复之前批准的配置。协调DKIM更改与提供商激活；在服务仍使用公钥进行签名的情况下删除公钥会导致新的失败。停用 Sendloop 时，请确认所有活动和自动化已停止，并在删除信任或跟踪记录之前检查共享SPF依赖关系。
SPF差异的虚构示例
仅虚构的书面案例：SLP-01 假定来自offers@workshop.example 。公共示例包含两个提供程序，而其现有策略指令指定了一个；当前帐户授权、信封身份和DKIM / SPF结果未知。 DNS所有者保留更改并要求帐户所有者获取特定于路由的确认。文本文件和品牌链接不建立身份验证。澄清后，团队将审查一项政策并收集受控的活动信息。未执行任何帐户、 DNS或发送测试。
纪录片报道和剩余的门
该草案涵盖了公众账户工作流程和安全验证。它不建立通用的专用 DKIM 或自定义Return-Path设置，也不声明已检查实时对齐的 Sendloop 消息。这些与帐户相关的详细信息、实时DNS和标头证据、独立审查、目视审查和 SME 人工批准仍然悬而未决。保留原来的完整实施范围，直到所需的账户证据弥补差距。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。