首先定义外展身份
新闻活动可能在编辑器中看起来正确，但通过意外的发件人身份离开。在更改DNS之前，请记录组织、预期发件人地址、负责外展的人员以及路线是活动还是个人推介。在此清单中包括现有草稿和集成。他们的发件人选择是验收测试的一部分，而不是从新闻编辑室的外观推断的细节。
Prezly 提供即用型prezlymail.com地址并支持经过验证的公司域地址。它是 发件人地址指南 描述添加地址、选择域名、发布三四次 CNAME 记录并运行状态检查。使用为所选域显示的值。公开文章中的示例标识了服务的设计；它们不是要复制到另一个组织区域的记录。
将网站和电子邮件配置分开
有效的新闻编辑室主机名并不是竞选电子邮件经过验证的证据。 Prezly 明确地将网站自定义域设置与发件人域准备情况分开 开发者指南。为DNS更改指定一个特定目的：授权批准的外展域，而不是在一次操作中修复每个品牌主机名。
捕获每个建议的记录所有者的当前区域值。记录DNS编辑器是否需要相对标签或完全限定名称。在继续操作之前，请管理员将生成的公共所有者名称与说明进行比较。重复的后缀， 一个记录 放置在错误的区域中，或者不兼容的所有者处的现有CNAME都可能会生成看似合理的条目，但无法通过预期检查。保留普通的商业邮件记录和不相关的TXT值。
对于拥有多个公共品牌的组织，请为每个域准备一个更改行。不要假设验证机构自己的域会授权所有客户身份。帐户所有者应批准哪些人可以使用每个身份以及哪些邮箱接收回复。在选择新的默认值之前应记录该操作决策。
发布已发布的授权而不扩大其范围
Prezly 文档 返回路径 子域和基于 CNAME 的身份验证委派。它还说现有 DMARC记录 不需要重新创建，并且Cloudflare记录必须使用仅 DNS 模式进行此设置。审查现有的 DMARC 在其所有者处添加任何内容之前的策略。不要仅仅为了使向导匹配而将更强大的批准策略替换为示例监控策略。这 发件人地址说明 还要求发件人域具有 MX记录;确认回复到达预期邮箱，而不是随意重定向入站邮件。
将每个CNAME视为正在进行的委派。将其提供商目标、业务目的、所有者和恢复说明放在一起。未来的DNS清理必须区分未使用的网站别名和邮件身份验证依赖项。如果提议的所有者与其他服务发生冲突，请停止该记录更改并寻求针对确切帐户的说明。猜测新的 选择器 或目标不是安全的冲突解决方法。
SPF 评估用于邮件的SMTP身份，而不是友好的显示名称。如果实际需要SPF策略，请在该所有者处保留一项策略并检查其完整的 DNS 查找成本。看 RFC 7208。不要仅仅因为测试消息提到外部传递平台就向根域添加广泛的授权。
检查接口和集成的准备情况
使用时间戳和所使用的指令修订版保存域状态检查。绿色应用程序状态之后应该是受控发送。它确认配置的一部分，而收到的消息则提供有关服务实际使用内容的证据。
对于集成，请检查预期的发件人 ID、地址、批准状态和域有效性。 Prezly 警告其序列化 is_verified 字段当前始终为 true，并且不是批准或DNS准备就绪的证据。它是 API指导 还建议明确的发件人 ID，而不是假设默认更改会重写现有草稿。让集成所有者确认所选身份，而无需在屏幕截图或审查文件中暴露 API 凭据。
如果更改默认值，请分别测试新创建的营销活动和相关的现有草稿。保存的对象可以保留其自己的身份。保持任何恢复过程精确：恢复批准的发件人选择或暂停受影响的外展，而不是在诊断应用程序设置时删除所有身份验证记录。
阅读收件人收到的消息
向受控外部邮箱发送无害的营销活动和无害的推介。当内部分发很重要时，包括内部邮箱作为单独的测试。捕获消息 ID、UTC 时间、发件人、 Return-Path 、 DKIM 签名域和选择器，以及最终接收者的可信认证结果。编辑不需要审核的收件人详细信息和活动内容。
DKIM通行证证明签名域的有效性。 DMARC另外还需要与可见的发件人域相关的对齐传递SPF或DKIM身份。 RFC 6376 定义签名字段，以及 RFC 9989 定义DMARC 结盟。记录有效的对齐方式；在严格对齐的情况下，相关的子域并不能自动满足要求。
不要使用收件箱放置结果作为整个身份验证结论。邮件可以通过身份验证，但仍然会因信誉、收件人规则、内容或发送行为而受到不利的过滤。相反，列入白名单的消息可能会出现在收件箱中，而不会证明公共身份验证路由是正确的。
Prezly 验收工作表
为营销活动、推介和任何集成驱动的路线填写单独的行：
- 组织、领域、企业主和路线：____。
- 预期发件人、回复邮箱和明确的发件人 ID（如果适用）：____。
- 现有草案或新创建的测试：____；选中默认选择：____。
- 已颁发的CNAME所有者和目标参考：____；已解决的冲突：____。
- 保留或批准的现有DMARC政策变更参考：____。
- 公共DNS答案、申请状态和验证时间：____。
- 受控收件人、消息 ID 和 UTC 发送时间：____。
- Return-Path 、 DKIM d= 和s=,可信SPF / DKIM / DMARC结果：____。
- 观察到的对齐机制和内部过滤结果：____。
- 释放所有者、恢复操作和下一次验证触发：____。
空的身份或接收者字段会使路由未经验证。仅当通信所有者和邮件管理员同意测试的身份是用于真正外展的身份时，才可以超出试点范围。
内部测试失败的虚构诊断
仅虚构示例：Alder Press 将其内部测试视为垃圾，并建议更换域的SPF策略。外部副本已对齐DKIM和DMARC通行证。内部收件人使用内部发件人地址将邮件识别为外部发起的邮件。普雷兹利的 交付能力指导 讨论这个内部测试模式。该团队在更改公共DNS之前会调查该接收者的策略。
狭窄的、经过审查的接收者例外可能适合记录的业务路线，但不得将其作为身份验证修复或外部交付的保证来呈现。当地址没有收到任何信息时，该团队还会检查抑制和退回证据。这个诊断是有说明性的；未观察到 Alder 帐户、 DNS区域或消息。
保持接受边界可见
在发件人更改、 DNS迁移、集成更改身份选择或丢失验证状态后重新检查。将记录清单和经过编辑的标题保存在一起，以便其他管理员可以重现结论。公共文档支持此程序，但实时租户检查、帐户发布的值、 DNS测试、接收消息证据、渲染的视觉审查、SME 人工批准和发布仍有待完成。
明确集成切换
对于集成驱动的营销活动，请保留数字发件人 ID 和发布记录。批准和域有效性是单独的字段；成功的对象创建和 is_verified=true 都不能替代。集成操作员应记录这些状态而不导出凭据，然后检查受控活动中实际选择的身份。这是建议的验收检查，而不是针对本文执行的 API 调用。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。