将成功定义为您想要的交付身份
可以在显示与活动所有者期望的发送域不同的发送域的同时交付 Selzy 活动。在开始身份验证之前，将所需的可见发件人、显示名称和回复目的地放入更改计划中。仅仅到达的测试不足以接受品牌发送身份的证据。
本指南涵盖了 Selzy 营销帐户工作流程。这 Selzy UniOne 页面的产品说明 提供单独的SMTP和 API 服务。如果您的应用程序通过 UniOne 发送，请确认该路由并使用其特定于帐户的说明，而不是假设营销活动设置会保留。同一品牌系列不会建立相同的选择器、包络行为或设置控件。
清点活动和自动化使用的每个域。包括从模板继承的变体或由不同工作人员选择的变体。将不同的领域和实质上不同的交付路线视为单独的测试。不要仅因为通用教程在插图中使用第二个域而添加它。
在请求域设置之前确认邮箱
Selzy 的设置指南，“将您的电子邮件添加到已确认的电子邮件” 从帐户 → 设置 → 帐户设置 → 确认的电子邮件开始。它需要先确认域上的地址，然后才能添加该域进行身份验证。使用组织控制和监控的地址。
确认邮箱表明可以访问该邮箱；它不发布密钥、在DNS中授权发送服务器或证明 DMARC 结盟。将确认事件保留在与DNS更改不同的工作表行中。如果确认消息未到达，请调查地址和邮箱，而不是更改不相关的地址和邮箱 SPF记录 盲目地。
决定当员工角色变更时由谁维护回复目的地。使用无害内容通过普通回复工作流程测试目标。避免仅仅因为方便初始设置而将个人不受监控的地址放入长期活动中。
获取账户当前的域名记录
这 Selzy DKIM指南，“在 Selzy 中创建DKIM记录” 将管理员引导至域身份验证、添加域并获取其设置。使用实际域显示的确切所有者、类型和公共值。记录源帐户和时间，以便其他管理员可以区分当前的说明和旧的设置屏幕截图。
在发布之前检查提议所有者的现有记录。如果 选择器 name 被占用，确定它是否属于同一帐户、较早的密钥或其他服务。不要仅仅因为教程显示了熟悉的选择器就覆盖它。出现冲突时寻求支持的解决方案。
仅发布公开验证材料。一个公众 DKIM 密钥不是秘密的，但私有签名密钥必须保留在授权签名系统中。请勿从帮助页面或其他组织复制示例密钥。不要缩短长密钥或更改其字符以适应DNS编辑器。验证编辑后完整返回的DNS值。
引用的指南的“如何测试DKIM身份验证”部分将DNS 、应用程序和真实消息检查分开。在变更记录中遵循该分隔。每个问题都回答不同的问题：密钥是否已发布、服务是否识别配置以及接收系统是否验证使用它签名的消息？
添加SPF ，无需重写邮件策略的其余部分
Selzy 的SPF指南，“如何添加SPF记录” 开始于 Return-Path 和发件人库存，然后获取当前帐户设置并发布一项策略。它显示include:spf.selzy.com作为服务授权。在实际域和现有发件人的上下文中检查该依赖性，而不是批量复制独立策略。
在提出更改之前保留当前政策及其企业主。邮箱平台、支持系统和其他应用程序可能已经依赖它。识别任何 重定向修饰符 以及结束一切的机制。一个看起来简单的替代品可以改变当没有早期机制匹配时发生的情况。
设置教程包含将重定向更改为包含并使用特定结尾的广泛说明。不要机械地应用该转换。这 SPF 指南的语法部分区分了这两种结构，并且 RFC 7208 ，第 5.2 节和第 6.1 节 定义了他们不同的行为。让邮件管理员检查整个策略并保留组织的预期语义。
RFC 7208第 4.5 和 4.6.4 节还涵盖了单策略选择以及对 DNS 查询机制和修改器的限制。计算嵌套查找。不要在同一所有者处创建另一个v=spf1记录，也不要仅仅为了使本地检查器变为绿色而删除不相关的授权。
SPF评估信封身份，而不是评估可见的发件人本身。从收到的消息中捕获身份并记录其是否一致。此审核并未为自定义Return-Path建立通用的营销活动帐户设置。如果对齐的SPF是硬性要求，请确认对确切路由的支持，而不是发明弹跳域字段。
读取启用状态以及实际DNS答案
在设置指南的状态说明中，Selzy 提供了 Enabled 状态和手动刷新控制。它描述了丢失记录或授权的延迟和错误消息。使用错误来识别失败的层，而不是重复地重新创建域。
如果报告密钥丢失，请查询帐户显示的确切所有者。检查是否有意外重复的后缀， 一个记录 DNS提供商错误、内容缺失或权威答案不一致。如果报告SPF缺失，请检查预期域的策略并将其与帐户的要求进行比较。当答案不一致时，记录解决者和时间。
不要将应用程序状态视为最终消息身份的证明。营销活动可以使用与您刚刚启用的域不同的“发件人”选择，或者计划的自动化可能会继承旧的设置。即使域面板看起来正常，仍然需要从实际路由进行新的受控发送。
明确检查发件人地址替换
设置指南的“为什么我的发件人电子邮件地址被替换？”部分介绍了在未启用DKIM或使用免费邮件发件人时使用 Selzy 共享域进行的替换。其回复部分解释了 Reply-To 是单独处理的。因此，记录发送的发件人地址，而不是假设它等于营销活动编辑的原始输入。
这种行为在测试期间尤其重要。在共享域下到达的营销活动可以通过该服务演示交付，而无需证明您自己的域已通过身份验证。不要将其视为自定义域要求的成功。保存请求的身份和观察到的身份之间的差异，并在重新测试之前更正预期域的设置。
单独验证回复。检查实际的 Reply-To 标头并将无害的回复发送到批准的受监控目的地。有效的回复路由不会修复DMARC对齐，并且对齐的活动仍然可以将回复发送到企业不监控的地方。两项检查都属于启动记录。
捕获最终的认证证据
通过将在生产中使用的相同营销活动或自动化路线发送给受控外部收件人。不使用客户名单、私人客户详细信息或生产订单内容。记录活动 ID、消息 ID 和 UTC 时间，以便支持人员可以关联交付，而不会收到不必要的数据。
捕获可见的 From 域、接收方报告的信封标识或Return-Path 、所有DKIM d= 和 s= 值以及接收服务的可信SPF 、 DKIM和DMARC结果。 RFC 6376 ，第 3.5 节 定义DKIM标识符。使用这些观察到的值来检查键查找，而不是从旧文章中猜测的选择器。
RFC 9989 ，第 4.4 节 通过对齐将经过身份验证的SPF或DKIM域连接到可见的 From。记录经过的对准机构和有效模式。服务域下的传递或重写的 From 下的传递不会证明最初请求的自定义身份的身份验证。
保留组织现有的DMARC政策，除非其所有者批准更广泛的更改。不要将初学者教程的监控示例或等待建议解释为禁用现有实施的权限。首先调查发件人。身份验证是传递的一部分，并不保证收件箱放置或消息安全。
使用发件人替换工作表
使用单独的审核记录，其中包含邮箱确认、帐户颁发的DNS记录、启用状态、请求和传送发件人地址、回复目的地和对齐的接收者结果。请求与观察的比较是有意的：它可以防止共享域回退被误认为是自定义域完成。
如果无法观察某个字段，请记录下一个所有者和操作。将外部消息证据与内部许可名单或测试模式结果分开。为每个有意义的发件人域更改、模板更新或活动和 API/ SMTP产品之间的移动添加重新测试。
虚构的工作示例：已交付的营销活动尚未准备好
仅虚构的书面案例：SZ-01 假设请求的发件人是promo@example.org ，但传递的消息使用共享 Selzy 域并保留 Reply-To promo@example.org 。确切的替换邮箱、签名域、选择器和SPF结果未知。有效回复不符合品牌标识要求。活动所有者应解决域身份验证问题，并收集新的外部消息，显示预期的发件人以及一致的身份验证，然后再批准该要求。没有进行帐户、活动或交付测试。
恢复而不隐藏原始问题
当无法证明所需身份时，暂停受影响的自定义域推出。保留现有的工作身份验证记录并与帐户和DNS所有者协调任何恢复。如果将共享域发送视为临时替代方案，请向企业主明确品牌和回复结果，而不是默默地将替代视为解决方案。
保留仍在运行中的消息所需的选择器，直到经过审查的退休计划允许删除为止。真实账户检查、 DNS观察、收到消息证明和精确的自定义信封支持仍待解决。这份未发表的文档草案还等待视觉审查和人类 SME 批准。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。