围绕记录的批准流程和日期进行计划
点击官方 电子邮件发送域指南，于 2026 年 10 月 6 日编辑，介绍了在 ClickDimensions Marketing Automation 中配置域。它宣布，从 2027 年 1 月 25 日开始，电子邮件只能从状态为“已批准”的域发送。截至 2026 年 11 月 9 日审查本指南时，这是未来宣布的限制，而不是证据表明新的强制措施已经在租户中发生。在计划更改之前，请确认适用的版本、帐户和当前提供商的通知。
该指南表示，必须涵盖发件人电子邮件地址中使用的每个域，包括不同品牌或地区使用的域。清点电子邮件发送记录中的实际发件人地址以及营销活动自动化中的发送电子邮件操作。不要假设组织的主域涵盖每个配置的发件人。帐户准备情况取决于实际的域列表和批准状态，本手稿均未检查这两者。
将DNS验证与已批准状态区分开来
记录的顺序包括等待DNS验证、等待批准和已批准。验证DNS记录后，域仍会经历 Click 的更改管理流程。该指南描述了每周的更换窗口，可能需要长达 7 天的时间，并表示 DKIM 预计在等待批准阶段后 1 至 7 天发布。这些是提供商的调度声明，而不是立即激活的承诺或独立验证的服务水平承诺。
尽早规划DNS工作，为审批流程和任何更正留出空间。绿色DNS检查不应输入为“已批准”，除非域的实际状态如此说明。记录负责提供者问题的联系邮箱，并确保授权人员对其进行监控。本文不会打开支持票证、提交域以供批准或声明已预订任何更改窗口。
输入具有正确范围的域和子域字段
导航至 ClickDimensions 设置和电子邮件发送域。该指南描述了发送域、 DKIM子域、可选电子邮件 CNAME 和联系电子邮件。子域字段采用标签而不是完整的完全限定名称。 DKIM子域必须是 Click 所独有的，不得为其他服务或目的而保留，并且使用不带前导或尾随标点符号的有效标签。 DKIM和电子邮件CNAME子域不能使用相同的标签。还要检查现有的网络内容和社交CNAME依赖关系，而不是在不检查所有权的情况下选择方便的标签。
可选的电子邮件CNAME用于电子邮件链接；它不能与DKIM子域互换。保持链接品牌， 返回路径 配置和签名证据单独记录在验收记录中。使用帐户为目标域生成的值。请勿复制其他品牌的标签或目标，因为它已经具有“已批准”状态。批准属于配置的身份及其记录，而不属于可重用的DNS模板。
保存后，指南描述了可能的组织域 SPF 改变，两个新的 MX记录 和五个新 TXT记录。记录整个发行集和每个所有者的目的。这些并不是替换组织根部普通入站MX记录的说明。在进行任何更改之前，请与DNS管理员一起检查生成的确切所有者名称和路由依赖关系。
保留提供商的DNS格式说明
该指南警告其齿轮的复制粘贴格式。 _domainkey条目，包括电子邮件客户端引入的换行符、空格和引号。它还表示其三个DKIM TXT值分别为 225、225 和 4 个字符，并且应在不串联的情况下创建。将这些指令应用于实际发布的记录，而不是将它们合并到单个发明的键值中或假设每个TXT记录都具有相同的格式。
DNS编辑器的表示与DNS返回的逻辑数据不同。 RFC 6376 ，第3.6.2.2节 定义DKIM密钥存储的TXT资源记录。保留提供商发布的记录边界并通过授权流程检查实际发布的数据。保存的输入框的屏幕截图不足以证明公共所有者和值是正确的。
该指南的“验证”按钮可检查记录是否存在并包含内容。该范围比完整的接收消息测试要窄。将实际验证结果、后续审批状态和最终签署证据分开保存。如果 一个记录 如果错误，请与DNS所有者更正具体的不匹配项，而不是重复提交批准或替换不相关的记录。
将轻松对齐视为产品先决条件
官方 DMARC实施指南，编辑于 2025 年 5 月 16 日，表示 Click 的子域设计不支持严格的 adkim 或严格的 aspf。它需要明确地或通过相应的默认值来宽松地设置两者的值。将其保留为记录的产品约束；不要将其软化为可选的性能建议，或者说该帐户可以使用严格模式而无需额外的证据。
这并不授权悄悄削弱组织现有的域策略。确定策略所有者、其他邮件流和预期的安全要求。如果当前政策与记录的产品设计相冲突，请在设计决策获得批准或当前提供商澄清之前阻止实施。不 DMARC 此处的策略已更改，并且本指南未声明不受支持的替代配置。
RFC 9989 ，第 4.4 节 定义协议的 结盟 规则。对严格对齐的通用协议支持并不意味着每个服务都实现兼容的路由。相反，提供商的限制并不意味着在任何地方都不可能严格对齐。在记录接受决定时，将这两个声明分开。不要仅仅因为发送平台受到组织的信任而将不相关的传递签名视为对齐。
一起查看SPF和实际邮件身份
帐户生成的SPF说明需要在完整的合法发件人清单中进行审查。 RFC 7208 ，第 2.4、3.2 和 4.6.4 节 定义 邮件来自、多个SPF策略行为并评估依赖于 DNS 的术语限制。不要用单一服务示例替换正在运行的组织策略，也不要添加竞争性的第二个示例 SPF记录。查看批准路线使用的实际返回路径标识。
经过单独授权设置后，无害的接受消息应建立作者域、返回路径域、签名域和 选择器，具有可信的接收器结果。 RFC 6376 ，第 3.5 节 定义签名字段。提供商级默认签名或成功的DNS验证本身并不能证明客户域路由一致。身份验证也不能保证收件箱的放置或活动的参与。
虚构诊断和空白接受工作表
虚构的分销商 Birchline Tools 完成了其第二个品牌的DNS验证，并在域仍在等待批准期间安排了一项活动。竞选团队将这种中间状态视为等同于生产准备状态。审查发现了两个缺失的决策：完成提供商变更窗口并确认品牌的DMARC对齐设置满足记录的产品要求。
建议的更正是保留已完成的DNS证据，同时保持发布开放，直到实际的域状态和策略决策得到解决。不得绕过审批、私自更改发件人地址或擅自削弱政策。这个虚构的场景不包含真实的租户结果、计划的活动或执行的测试。
- 帐户版本和所有实际发送域：______
- 生成的DKIM子域、可选链接域和记录集：______
- 现有依赖项和权威DNS批准：______
- 所需的宽松 adkim/aspf 兼容性决定：______
- DNS验证结果，等待批准并获得批准的证据：______
- 受监控的联系人和提供商变更窗口计划：______
- 电子邮件发送和营销活动自动化来自域检查：______
- 可信消息级身份和对齐结果：______
- 未解决的条件、回滚所有者和发布决定：______
原始实施证据、人类主题审查、当前适用性、生产路线、视觉可达性和所有者发布仍然开放。未提交域名、编辑DNS 、更改策略或发送电子邮件。该目录更广泛的实施要求仍然取决于授权帐户和消息证据。