Mailchimp的域验证和域身份验证是单独的步骤。验证可访问相关电子邮件身份；身份验证配置发送工作流的域。两者都不应与使用预期身份到达接收者的特定活动的证据相混淆。
从帐户、营销活动的可见发件人地址中的域以及正在评估的营销活动路线开始。记录谁拥有该域以及谁可以授权更改其活动DNS 。
识别发送产品和当前状态
Mailchimp的当前指南包括自动和手动身份验证路径。确定帐户使用的路径以及域是否已经过验证或身份验证。
保持产品范围明确。如果企业使用Mailchimp交易以及营销活动，请确认每条路线的适用设置和测试要求。出现在同一系列产品中的品牌不建立共享配置。
使用组织控制的域。公共邮箱地址无法授予组织发布该邮箱提供商域的身份验证记录的权限。
将生成的记录与现有区域进行协调
对于当前的手动工作流程， Mailchimp记录了两个 DKIM CNAME 和 DMARC TXT记录。使用相关帐户中生成的值，而不是记住的值 选择器 或复制的客户目标。
检查每个建议名称的现有数据。新记录不得覆盖活动选择器，并且建议 DMARC记录 需要根据已经生效的政策进行审查。帐户设置过程并不是批准重置更强大的运营策略或删除报告目标。
不要仅仅为了满足其他服务而在同一所有者名称下创建第二个DMARC策略。确定适用的现有策略是否满足配置需求，并通过支持的验证过程解决任何分歧。
对于自动连接，请在授权之前检查其预期的DNS更改和访问范围。保留实际结果记录。自动化写作仍然需要可追溯的所有者和可理解的结果。
验证公开答案和账户结果
检查活动权威主机上的确切所有者名称。确认DNS编辑器如何处理完整主机名，以及它是否保留预期的主机名 CNAME 目标。
记录公开答案和时间以及Mailchimp的验证状态。正在进行的状态需要对发布和验证进行调查，而不是重复删除和重新创建记录。
如果验证失败，请将每个请求的记录与其权威答案进行比较，并检查记录类型或所有者名称冲突。避免改变不相关的 SPF 策略或入站邮箱路由，但没有证据表明它们涉及。
通过活动路线发送
使用受控收件人和适当的活动测试。保存原始收到的消息以及帐户和活动参考。
检查可见的发件人域、 DKIM签名域和受信任的接收者结果。建立支持DMARC一致身份验证路径。单独的策略TXT记录无法创建签名或修复不相关的身份。
一个综合的例子说明了这种区别。团队验证对地址的访问并在其帐户列表中发现没有问题，但从未完成域身份验证。下一次调查应将该帐户状态与生成的DNS要求和真实的活动消息进行比较。重复重写DMARC策略将跳过丢失的设置证据。
如果活动通过了身份验证，但仍然变成垃圾邮件，请保留该结果。身份验证和放置回答不同的问题。分别调查当前的接收者要求以及活动的接收者、声誉和内容因素，而不是撤消经过验证的身份配置。
保持广告活动变更可维护
记录帐户、发送产品、域、生成的记录集、更改所有者和接收消息证据。包括停止为组织发送信息的机构或帐户的退休流程。
当发件人域或帐户发生更改时，请检查设置。保留活动路由所需的记录，直到验证报废为止，并重新评估旧的依赖关系，而不是在没有所有者的情况下无限期地保留它们。
发件人库存将此营销活动路线与更广泛的计划连接起来。有用的结果是团队可以维护的特定的、经过验证的身份，而不是每个活动都会到达收件箱的无条件承诺。
将活动检查分离到决策分类账中
对于虚构的营销活动 MC-01，规定来自news@example.com通过电子邮件访问进行验证，而域身份验证仍处于待处理状态。尚未提供 CNAME1 和 CNAME2 生成的值，假定现有DMARC p=reject，并且收到的DKIM / SPF结果未知。保持活动未经验证；不要用以下内容取代现有政策 p=none 或者发明DNS目标来强制完成。获取帐户生成的名称，将每个名称与权威区域进行协调，然后收集受控活动的原始名称。单独的交易应用程序保留在该活动结果之外。未执行任何帐户、 DNS连接或活动发送。
更改 CNAME 的Mailchimp文档可能需要禁用并重新验证域。计划由变更负责人进行维护并确定受影响的活动；不要仅仅因为出现不相关的交付问题而重复重置工作配置。
保留执行边界
RFC 9989 对于发布p=reject,第 7.4 节要求有效的DKIM而不仅仅是SPF ，并就间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。