从子域和发件人配置文件一起开始
Sendlane 部署有两个相互关联的部分：经过验证的发送子域和实际使用它的发件人配置文件。在测试活动之前完成这两项工作。 Sendlane 将验证的子域记录为其所需的发送模型，并且不提供主域验证。其委托方法使 Sendlane 可以控制选定的子域，而主域则保留其现有的 名称服务器。子域在发件人地址中仍然可见。 Sendlane 验证概述、主域和名称服务器问题.
决定谁拥有营销发送、 DNS 、安全策略和回复。在更改共享配置文件之前，清点计划的活动和活动的自动化。包括具有不同特征的品牌或地区，并记录其中哪些可能会一起改变。这里的范围是 Sendlane 活动和自动化邮件。它不建立不相关的事务集成、店面收据或公司邮箱服务的身份。
使用为此目的批准的未使用的子域。对于一种记录类型没有显示答案DNS查找并不能证明某个名称未被使用。检查区域、委派子项、网站配置、证书、应用程序设置和其他电子邮件提供商。如果提议的名称已经在服务某些内容，请选择其他名称或获取单独批准的迁移计划。不要为了验证成功而删除不熟悉的记录。
从此帐户获取DNS方法
设置页面选择四个 NS 记录或一组包含一个MX 、两个 CNAME 和两个 TXT记录。其记录的路线是“帐户”>“电子邮件”>“设置域”，然后是主域和发送子域字段。尽管 AWS 支持 NS 记录，但该指南专门通过支持将 AWS 用户路由到CNAME / MX / TXT方法。它还指出 Wix 和 Hostgator 都不支持任何已记录的方法； DNS 主机迁移需要有自己批准的计划，而不是临时删除现有记录。 Shopify 用户将被定向到单独的 Shopify 指南，因此此一般过程不能替代该路线。将当前帐户输出和提供商确认视为执行权限，而不是记住的DNS配方。 Sendlane 设置指南，步骤一到三.
保存每个颁发的所有者、类型、值、TTL 和任何MX优先级的带日期的副本。请勿用帮助文章中的演示域或名称服务器值替换帐户的当前说明。如果可见记录与DNS主机的功能冲突，请在此时暂停并获取支持的方法。这比实现每种方法的一半或尝试将委托转换为猜测的TXT记录更安全。
对于基于 NS 的设置， DNS审核必须明确识别所委派的子区域。验证更改是否位于主域下方。更改注册商的默认名称服务器所影响的不仅仅是 Sendlane 邮件。与第二位审阅者确认范围并保留父区域的更改前导出。仅在业务和安全所有者批准该信任边界后才进行委托。
发布并检查每条发布的记录
在权威DNS服务处应用记录集，该服务可能与注册商不同。检查其编辑器是否附加区域后缀。已包含完整名称的主机字段可能会意外生成重复的域。保存后将生成的完全合格所有者与提供商发布的名称进行比较。
NS 授权需要来自区域划分双方的检查：父母的推荐和孩子的权威答案。对于替代方法，请分别检查每个CNAME 、 MX和TXT 。一个键的绿色勾号并不能证明其他记录是正确的。保留所有无关记录，并将前后差异与变更机票一起保存。
当TXT记录包含 SPF 政策，查看该确切所有者的完整政策。同一所有者的多个SPF策略无效，并且 DNS 查询SPF术语具有十个术语评估限制，包括嵌套依赖项。不要仅仅因为它是最熟悉的域而将 Sendlane 权限添加到公司 apex。查看实际用于SPF的域。 RFC 7208 ，第 4.5 节和 4.6.4 节.
返回 Sendlane 并使用验证DNS记录。该指南最多允许 24 小时进行初步验证；比较DNS答案，而不是在缓存过期时重复更改它们。保存提供者的记录状态和观察时间。提供者状态是一个接受层，而不是收到消息的证明 结盟.
绑定个人资料而不丢失活动覆盖范围
Sendlane 的设置说明需要新的或现有的发件人配置文件来选择“已验证”选项，并在“发件人电子邮件”选择中选择已验证的子域。单独查看回复处理：概述描述了使用经过验证的发件人和回复域的经过身份验证的配置文件，而设置表单则请求回复地址。确认帐户允许的回复配置和实际监控的目标，而不是假设任意覆盖。 Sendlane 设置指南，第四步.
检查打算使用该配置文件的每个活动或自动化。帐户设置中未使用的经过验证的域不会更正其他地方的过时配置文件。记录配置文件名称、显示的发件人地址、预期回复邮箱以及引用它的工作流程。在受控窗口中进行更改，以便在DNS验证和配置文件审核之间无法启动计划发送。
不要假设更改回复地址会更改身份验证。它是响应的操作目的地，应测试其是否正确路由，但它不是针对其的发件人身份 DMARC 对齐进行评估。还要避免将品牌点击跟踪主机名视为 信封发件人。即使邮件在收件箱中看起来一致，这些字段也可以属于不同的域。
检查活动和自动化交付
使用无害的内容和受控的外部收件人。通过活动路线发送一项测试，通过使用生产配置文件的代表性自动化发送一项测试。当涉及不同的配置文件、品牌或材料交付路线时重复此操作。记录 UTC 时间、活动或自动化标识符以及消息 ID，以便支持人员可以找到相同的消息。
保留收件人的原始标头和受信任的身份验证结果。记录可见的From域，SPF验证的信封域， Return-Path， 每个 DKIM 签名域名和 选择器，以及接收者的SPF 、 DKIM和DMARC结果。签名域和选择器告诉验证者在哪里找到密钥；它们不能与发件人配置文件标签互换。 RFC 6376 ，第 3.5 和 6.1 节.
确认哪种传递机制与策略的对齐模式下可见的From对齐。不相关的服务身份的通行证本身是不够的。将所选子域的策略和任何相关的父策略保留在证据中，以便审核者可以重现结论。 RFC 9989 ，标识符对齐解释和DMARC评估.
本指南不承诺提供单独的、用户可选择的自定义Return-Path功能。公共来源建立域验证和配置文件，而不是每个租户的信封控制。如果缺少所需的严格对齐结果，请从 Sendlane 获取支持的身份选项，并在批准该要求之前检查新消息。
解决正确层的故障
如果无法验证记录，请首先确认权威DNS提供商、确切的所有者名称、记录类型以及子域的任何现有使用情况。如果公共DNS正确但帐户仍未验证，请保留已发布的记录集和定时观察以获取支持。当计划的发送仍引用该域时，请避免删除并重新创建该域。
如果DNS已验证，但收到的发件人是意外的，请在更改密钥之前检查所选的配置文件和活动或自动化参考。如果DKIM不存在，请确认测试的工作流程确实使用了该配置文件。如果DKIM失败，请将其实际选择器与DNS进行比较，并在签名后调查消息更改。如果身份验证通过但DMARC失败，请检查域比较，而不仅仅是绿色结果标签。
递送警告并不授权削弱组织的DMARC政策。与保单所有者和提供者一起诊断失败的身份。同样，内部白名单可以掩盖外部收件人仍然遇到的问题。使用受控接收器来评估正常的传送路径。
保留工作表并排练恢复
使用以下字段为 Sendlane 实施工作表创建单独的审核记录。每个子域和配置文件组保留一份副本。记录发布的记录、 DNS证据、受影响的工作流程、接收者结果、协调机制和批准发布的人员。仅在需要时将公钥放入证据中；切勿包含凭据或私钥。
在发布之前，决定如何暂停新的活动和自动化，并在测试失败时将受影响的工作流程返回到之前批准的身份。不要先删除委派：这样做可能会在邮件仍在发送时删除身份验证答案。保留排队或已传递消息的证据，并在删除过时的信任之前就停用窗口达成一致。将移动DNS提供商、更改所选域或更改配置文件视为重新测试的原因。
未绑定配置文件的虚构示例
仅虚构的书面案例：SL-01 规定了一个营销活动配置文件，其中包含 From offers@news.example并传递d=news.example.欢迎自动化仍然使用welcome@old.example引用旧的配置文件；其DKIM和SPF身份/结果未知。营销所有者必须检查自动化的绑定并在批准该路线之前获取新的受控消息。活动结果无法缩小自动化差距。未执行任何帐户、 DNS更改或消息测试。
验证后计划控制发送
设置指南的第五步指导操作员预热已验证的域。不要将成功的DNS和标头检查解释为立即发送完整卷的权限。与交付能力所有者商定渐进的、基于同意的发送计划并监控结果；本指南并未规定通用费率或声称任何 热身 被处决。
接受仍然是一个证据决定
仅当预期工作流程使用批准的配置文件、公共DNS与已发布的记录集匹配、Sendlane 验证配置并且收到的消息证据显示所需的对齐通过时才发布。身份验证并不能保证收件箱的放置或良好的发送声誉。对于此未发布的草案，实时租户访问、实时DNS和消息测试、独立技术审查、目视审查和 SME 人工批准仍有待确定。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。