首先选择内置发送或自定义SMTP
Customer.io 的电子邮件身份验证文档将其内置递送服务与自定义SMTP区分开来。对于内置交付，需要使用域身份验证 SPF 和 DKIM。对于自定义SMTP ，它将身份验证责任交给SMTP提供商，而不是要求在 Customer.io 内进行相同的域身份验证设置。这是配置计划中的第一个决定。
记录工作空间、传递路线、预期发件人域和消息类别。确定迁移或异常是否导致某些消息使用其他传输。单个应用程序可以编排多个传递路径，因此一个路径中经过验证的发送域并不是该应用程序触发的每条消息的证据。
本指南描述了记录的内置工作流程以及自定义SMTP边界。它不会断言特定的 Customer.io 工作区已配置、已输入任何凭据或任何收件人已收到测试消息。更广泛的实施接受仍然开放。 Customer.io 电子邮件验证
使用生成的子域记录
内置服务提供与所选发送域相关的域身份验证记录。 Customer.io 解释说，其配置使用特定于 Customer.io 的子域（以特定于帐户的 cio 标识符进行说明），而不是接管根域。保留工作区中实际生成的所有者名称和值；该插图不具有复制到每个客户区域的价值。
该文档明确将此SPF配置与根域的SPF策略分开。不要仅仅因为配置了其他发送服务就将猜测的 Customer.io 包含添加到根记录中。在提交DNS更改之前映射帐户生成的子域和每条记录的用途。
DNS管理员应检查权威区域、现有记录和编辑器约定以获取完全限定名称。查看完整的建议记录集，而不仅仅是看起来与DKIM最明显相关的公钥。成功的计划会保留不相关的邮件基础设施，同时建立预期的特定于提供商的依赖关系。 我们不会接管您的根域；手动认证
选择受控的发布工作流程
Customer.io 记录了自动身份验证选项和手动DNS发布。自动帮助程序可能涉及对DNS提供商的访问；该访问是一个单独的安全决策，而不是通过阅读设置指南授予的默示许可。本手稿建议对生成的更改进行手动审核，以便现有DNS所有者可以通过既定控制来批准和应用预期记录。
准确复制所选域说明中的记录类型、所有者名称和值。保留之前的状态和更改参考。对于长DKIM TXT数据，区分一个字符串中的多个带引号的字符串 TXT记录 来自多个独立记录。不要截断密钥以适应假定的接口限制或发布多个冲突的密钥记录，因为显示会换行文本。
正确的接受目标是以预期名称发布的数据。 DNS编辑器的屏幕截图可以支持更改历史记录，但它们本身并不能确定外部接收器可以检索的内容。 手动验证您的域名； DNS提供商常见问题解答; RFC 1035 ，第 3.3.14 节
激活前协调DMARC对齐设置
Customer.io 的内置交付指南需要宽松的 aspf 和 adkim 设置来进行记录的设置。它还指出，省略了 结盟 标签使用宽松的默认值。如果该组织当前 DMARC 策略明确要求严格对齐，将其视为需要域所有者决定的设计冲突，而不是为了满足产品清单而随意删除的标签。
仔细使用协议术语。可见的作者地址位于RFC5322 From 字段中。 SPF评估SMTP身份，包括 邮件来自，而DKIM具有由d=. DMARC在适用的对齐模式下将相关传递身份与作者域进行比较。返回路径和可见的发件人地址不应在证据工作表中交换。
策略更改可能会影响使用同一域的其他邮件。在决定如何适应路由之前，请考虑现有的发件人清单、子域设计和安全要求。提供商要求并不能证明放宽组织的策略在每种情况下都是授权的或适当的。 放松你的 aspf 和 adkim 标签; RFC 9989 ，第 4.4 节; RFC 7208 ，第 2.4 节
请求验证并保持链接跟踪分开
发布所需记录后，使用 Customer.io 中的验证域。该文档称验证是在请求时发生的，而不是通过连续轮询进行。因此，等待接口自动发现更改的团队可能会将未请求的检查误认为是DNS故障。在进一步调查之前记录检查时间和实际结果。
品牌链接跟踪是另一种配置，具有自己的域和 CNAME 验证要求。它与验证电子邮件的签名或信封身份不同。同样，即使SMTP提供程序处理邮件身份验证，自定义SMTP仍可能涉及单独的跟踪域设置。将这些状态指示器保留在单独的工作表行中。
当检查失败时，首先将选定的工作区、域和生成的记录列表与实际建议的DNS更改进行比较。不要仅仅因为跟踪状态不完整而重复更改不相关的根记录或更改DMARC策略。用最少的证据升级特定的未解决部分。 验证域名；自定义SMTP和链接跟踪指南
工作区移交验收工作表
使用此建议的工作表可以防止多个绿色状态指标合并为一个不受支持的就绪声明。
- 传输清单：列出内置传递、自定义SMTP例外以及分配给每个路由的邮件。
- 发送域：保留选定的工作区、发件人域和实际生成的子域标识符。
- DNS规划：记录每个需要的所有者、类型和值、权威区域和批准参考。
- 对齐决策：记录现有的 aspf/adkim 设置以及域所有者对任何严格对齐冲突的解决方案。
- 提供商检查：保留请求验证域的时间及其返回结果。
- 跟踪检查：单独记录是否使用品牌跟踪域以及适用哪种验证。
- 消息证据：保留最小化的授权样本，其中包含作者、信封和签名身份以及可信的验证结果。
- 发布所有权：确定谁将审查路线更改、淘汰未使用的依赖项并批准生产准备情况。
该工作表是最初建议的控制措施。这份手稿的存在，其中的任何一行均不完整。
虚构的诊断：等待从未要求的检查
一个虚构的教育平台发布为其内置 Customer.io 路线生成的记录。几个小时后，管理员检查界面，发现该域仍未验证。假设根 SPF记录 是错误的，一位同事建议在那里添加另一种机制。更改请求不包含将该根策略连接到生成的子域的证据。
相反，审阅者确认没有人在发布后选择验证域。建议的下一步是请求记录验证，检查其实际结果，然后仅调查未解决的记录。品牌跟踪仍然是一项单独的未完成任务，在审查授权样本之前，不会对收到的消息对齐做出任何声明。此虚构诊断不会报告真实帐户事件、实时DNS查询或成功测试。