确定 Cision Communications Cloud 路线的范围
Cision 的“设置 SPF 和 DKIM于 2024 年 10 月 7 日发布的文章明确讨论了通过组织域发送的 Communications Cloud。其具体实施说明描述了支持辅助的DKIM ：组织提供完整的发送域，Cision 准备身份验证数据，域的DNS管理员发布提供的数据 CNAME 记录，Cision 验证结果。这是这里介绍的产品路线。它不是每个 Cision、Brandwatch、美通社或代理机构集成的通用配置。经常账户的适用性和实际生成的记录尚未得到验证。 Cision 设置指导
首先命名帐户、Communications Cloud 消息类别以及为可见发件人地址建议的域。记录组织是否拥有该域或使用客户的身份。运营活动的人可能无法控制其DNS ，并且商业关系不会自动授权发布身份验证记录。在任何实施步骤之前，确定域所有者并获得适当的变更批准。本指南建议进行审查；尚未访问任何帐户或客户域。
在请求身份验证之前同意域
提供商表示需要使用完整的域名并允许普通域名 组织域 或单独排列的子域。将这种选择视为范围决策，而不是化妆品标签。子域可以帮助记录不同的路由，但它仍然需要所有者、 DNS发布计划以及对传出消息实际使用的身份的审查。不要发明特定的子域名或假设提供商将验证所选域的每个后代。 Cision 设置指导
准备一份简明的内部交接，标识批准的发送域、企业所有者、Cision 帐户上下文和DNS运营商。让私人凭证和消息内容远离这种交接。随后的支持交流应该请求精确帐户和域的当前记录，而不是询问复制的示例是否看起来合理。本手稿不提供任何 Cision 选择器、 CNAME目标或记录计数，因为保留的指令不建立可重用值。
该指南描述了 Cision 在客户发布记录之前自行准备身份验证。这种顺序很重要： DNS管理员无法仅通过创建任意类似 DKIM 的名称来完成服务端配置。相反，支持准备 一个记录 并没有确定权威区域现在为其提供服务。为提供商准备、授权DNS发布和提供商验证维护单独的检查点。 Cision 设置指导
明确处理代理和客户所有权
Cision 专门针对使用客户电子邮件地址发送邮件的机构。它表示客户的 IT 组织必须在客户的DNS中发布身份验证。如果不可能，提供商建议使用该机构自己的域。这是有意义的身份更改，而不是保留客户原始经过身份验证的身份的解决方法。获得对收件人将看到的地址以及如何处理回复的批准。 Cision 设置指导
每个客户域创建一个所有权行。包括授权请求者、 DNS批准者、负责帐户和下线联系人。避免将多个不相关的客户归入单一假定授权之下。当合作结束时，检查哪些身份验证依赖项仍处于活动状态，并与提供商和域所有者协调其停用。当另一条批准的路线仍依赖于这些记录时，请勿删除这些记录。这些是建议的生命周期控制，而不是关于特定 Cision 租户自动化的断言。
无需猜测即可发布所提供的记录
DNS运营商应将每个提供的CNAME所有者和目标与预期的完整域名进行比较。与输入DNS编辑器的字符串分开记录完全限定所有者。编辑者的不同之处在于他们是附加区域后缀还是期望完整的名称。如果后缀重复，看起来很熟悉的记录仍然可能以错误的所有者的身份发布。将批准的源指令与建议的更改一起保留，而不是从记忆中重建它们。 RFC 1035 ，第 5.1 节
对于DKIM ，消息的选择器和签名域引导接收者找到公共验证材料。记录的存在本身并不证明消息已签名、使用了相应的密钥或签名在后续处理中幸存下来。因此，当授权证据可用时，提议的接受计划将提供者的记录集与实际接收到的消息身份联系起来。不要用任意选择器查找来检查预期路由上的签名。 RFC 6376 ，第 3.5 节和3.6.2.2节
Cision 文章的标题提到了SPF ，但其具体设置顺序不提供一般的SPF包含或特定于租户的信封配置。请勿使用其他 Cision 产品或不相关的第三方配方的值来填补该空白。请求实际路由的适用发件人授权信息，并将其与域的现有合法发件人进行协调。在确定这些细节和实施证据之前，更广泛的目录配置要求仍然开放。
将SPF 、 DKIM和DMARC身份分开
SPF评估适用的SMTP 邮件来自 或者 HELO身份，而不是直接验证可见的作者地址。将SPF发布为TXT并维护一项适用的身份策略。添加另一个独立的SPF策略不会合并权限，并且可能会产生永久性错误。如果提出新的授权，请检查评估的依赖路径和 DNS 查询术语限制，而不是仅计算第一个记录中可见的包含内容。 RFC 7208 ，第 2.3–2.4、3.1–3.3 和 4.6.4 节
DKIM验证建立与其签名域关联的签名结果。 DMARC 然后考虑合格的SPF或DKIM标识符是否与可见的发件人域一致。这些评估应在验收记录中保留单独的栏目。提供者验证状态不是收到消息的DMARC结果，并且通过但不相关的签名本身是不够的。 RFC 6376 ，第 3.5 节 RFC 9989 ，第 4.4 节
不要将垃圾邮件文件夹结果解释为身份验证是唯一缺陷的证据。身份验证可以提供有用的证据，而声誉、内容、收件人行为和本地过滤决策仍然会影响治疗。 Cision 的可交付性讨论不应成为其记录发布后将每一次新闻通讯都放入收件箱的保证。同样，经过身份验证的域并不能证明消息的事实断言或业务请求是安全的。 RFC 9989 ，第 2.4 节
虚构诊断：客户端域从未获得批准
考虑一个虚构的机构，港口新闻办公室，为客户准备通信云公告。活动运营商选择客户的可见地址，但将DNS请求发送给该机构自己的管理员。该管理员可以编辑代理区域，但不能编辑客户的区域。拟议的完成说明表示身份验证已准备就绪，因为机构域中存在类似名称的记录。这是一个虚构的审查场景，而不是观察到的事件或测试结果。
审查在发布前确定了所有权不匹配的情况。客户端要么授权自己的DNS团队实施特定于帐户的记录集，要么使用代理域批准不同的发件人身份。该团队在其活动和应对计划中保留了独特性。提供商验证和收到的消息证据仍有待确定；没有人会将错误管理域中的记录视为所请求身份的证明。
空白验收工作表
- 通信云帐户和消息类别：____。
- 已批准可见来自域和组织所有者：____。
- 代理或客户领域关系和明确批准：____。
- 当前提供商适用性确认和日期：____。
- 提供商提供的CNAME所有者、目标和请求参考：____。
- 权威DNS运营商和预期完整名称：____。
- 现有的发件人依赖性和未解析的SPF路由信息：____。
- 提供商准备、 DNS发布和提供商验证规定：____。
- 授权接收消息选择器、签名域和 结盟 证据： ____。
- 剩余决策、回滚所有者和发布批准者：____。
所有条目都故意留空。原始实施证据、人工/中小企业审查、来源适用性、生产路线、视觉/可访问性审查和所有者发布仍然开放。此草案未执行任何支持请求、 DNS更改、租户测试或消息发送。