确认这是 Marketing Cloud Engagement
本指南涵盖通过Salesforce Marketing Cloud Engagement 发送的电子邮件。它不适用Salesforce CRM DKIM 将工作流程、客户参与度配置或 Marketing Cloud Next 设置设置为参与度。在选择设置过程之前，记录产品、租户环境、企业 ID、业务部门成员 ID 和批准的发件人域。相似的产品名称并不能证明相同的DNS记录或接口适用。
重要的初始决定是组织是否需要单独发送经过身份验证的发送，或者还需要品牌消息链接和图像。 Salesforce将私有域与发件人身份验证包（此处缩写为 SAP）区分开来。本指南中的 SAP 是Salesforce产品名称，而不是单独的企业软件供应商。私有域产品不包含专用 IP，也不包含品牌链接或图像域。 Salesforce私有域常见问题解答
将许可证、发送基础设施和域控制视为先决条件，而不是在活动启动期间即兴完成的任务。与帐户所有者确认可用的权利。本文档并不授权购买域产品或接受合同。如果现有包可以满足要求，请避免仅仅为了删除收件人收件箱中的显示标签而设计迁移。
将发送权限与品牌分开
Salesforce将 SAP 描述为一个捆绑包，其中包括帐户品牌、私有发送域、IP 配置和回复管理功能。其文档将 Salesforce 托管的设置与需要客户团队参与的 Hyperforce 安排区分开来。业务部门的品牌配置可能与用作发件人地址的多个私有域不同。 Salesforce发件人身份验证包
映射每个域的业务原因。一个域可能代表可见的发件人，另一个域可能支持退回处理，其他域可能托管图像或跟踪点击。成功的 HTTPS 链接测试不会告诉您哪个域签署了消息。同样，一个路过的 DKIM签名 不能证明取消订阅体验、图像或回复目标正常工作。
选择适合组织设计的未使用的发送子域。在更改任何授权之前，请清点提议名称及其下方的现有网站、邮箱、验证记录和其他应用程序。委派区域会更改负责其记录的人员。安全审查者应该在批准之前了解操作责任。不要为了解决小范围的活动问题而替换整个公司域的权威名称服务器。
配置支持的域路由
记录的入口点是“设置”，搜索“ssl”，然后搜索“域 SSL 证书”。使用新域并选择所需的身份验证或身份验证和品牌范围、可用的 IP 安排、回复处理和DNS管理方法。保留选择和生成的指令。对于自托管DNS ， Salesforce在发送域操作菜单上提供下载区域文件。对于委派DNS ，请使用当前提供的委派说明。 Salesforce域配置
让DNS管理员在应用生成的记录之前检查它们。 The review should compare each proposed owner with what already exists, identify whether a name is relative or fully qualified in the DNS console, and explain each record's purpose.导入的区域文件不应默默地替换不相关的生产数据。保留已发布文件、租户协会和批准的变更计划的注明日期的副本。
不要键入从其他参与帐户记住的选择器或记录目标。当前特定于环境的指令优先于通用示例。如果所需的许可证或配置选项不可用，请要求帐户所有者或Salesforce解决该问题，而不是借用核心 CRM 身份验证工作流程。当租户的环境或域托管安排与公共示例不同时，这一点尤其重要。
区分DNS识别和激活
Salesforce记录了三种发送域状态：待定DNS验证、进行中和活动。中间状态表示DNS检测后正在继续安装。不要假设已发布的记录立即使发送方可用，从而安排生产切换。记录状态和观察时间，并在域仍处于意外状态时获得确认。 Salesforce域配置
对于每个业务部门，确认目标域可用作经过身份验证的发送域。 Salesforce的私有域常见问题解答描述了业务部门通过发件人地址管理的使用情况。域在企业中某处的存在并不能证明特定的发件人配置文件或旅程使用它。 Salesforce私有域常见问题解答
验收记录应标识准确的发送配置，而不仅仅是营销部门。包括受控活动、任何独特的交易或触发路线以及正在发布的业务部门。保持所有测试收件人的授权，并避免使用客户数据扩展作为故障排除捷径。安全测试不应产生意外的订单、提醒或面向客户的承诺。
验证收到的邮件的身份验证
在您控制的接收器上捕获原始消息。记录可见的发件人域、 SMTP信封身份、 DKIM签名域和选择器以及接收者的可信身份验证结果。签名的 d= 值标识其签名域，s= 选择相应的DNS密钥。当有多个相关签名时，保留所有相关签名。 DKIM RFC 6376
评价 结盟 与域的有效策略下实际可见的 From 域相同。 DMARC 需要传球对齐 SPF 或DKIM路径。传递不相关域的提供商签名是不够的，成功的SPF评估不会自动建立对齐。使用当前的DMARC规范，而不是将任何绿色身份验证图标视为完整的证据。 DMARC RFC 9989
对于SPF ，检查接收者实际评估的身份。在该所有者处维护一项适用的策略，并考虑 DNS 查找预算，包括嵌套评估。不要仅仅因为两种服务共享一个公司名称而将Salesforce CRM SPF包含粘贴到参与设计中。发布的配置和消息路由必须支持更改。 SPF RFC 7208
如果激活后身份验证失败，请将邮件与所选业务单位、发件人域和已发布记录进行比较。不匹配可能是配置选择问题，而不是密钥损坏。如果DKIM通过但DMARC失败，请调查域对齐。如果通过和交付仍然受到影响，请保留接收者响应并单独调查声誉、同意或内容，而不是重复替换身份验证记录。
独立测试回复和品牌资源
使用受控回复来确认预期的邮箱或回复管理路由收到它。检查代表性图像、跟踪链接、网络视图链接以及启用这些功能的取消订阅操作。记录实际的主机名和结果，而不假设每个品牌资产都使用相同的配置。不要在公共实施工作表中包含特定于收件人的跟踪令牌。
在替换活动域之前规划恢复。在可行的情况下保留以前支持的发件人路由，并定义在测试失败时谁可以暂停活动。删除旧的品牌记录可能会破坏已发送邮件中的链接。保留这些依赖关系，直到其所有者批准退休。恢复电子邮件发件人选择可能比删除多个工作流程现在依赖的委托更安全。
具有两个业务部门的虚构示例
仅虚构的书面案例：MC-01 规定零售单位发送notices@news.example ，并带有传递签名d=news.example.支持单位打算使用service@care.example ，但其域名仍在进行中，发件人可用性、 DKIM和SPF结果未知。支持所有者必须等待激活并验证自己选择的路线；零售结果并未接近支撑接受。未测试任何租户、域或活动。
实施工作表和发布限制
为每个域和业务部门路线填写一张工作表：
- 范围：参与环境、企业 ID、成员 ID、所有者、发件人身份和发送类型。
- 产品决策：当前权利、仅认证或品牌范围、批准的 IP 和答复安排。
- DNS更改：发布的文件或委托指令、现有依赖项、确切的公共所有者和值、审阅者、TTL 和时间戳。
- 激活：观察发送域状态、提供商确认、经过身份验证的域可用性以及测试的发件人选择。
- 消息证据：测试参考、接收者、发件人、信封标识、 DKIM d=/s=值、身份验证结果和对齐决策。
- 功能检查：回复传递、链接、图像、取消订阅、恢复路线和退休依赖性。
实时租户配置、 DNS答案、收到的标头、当前屏幕截图、目视审查和 SME 人工批准仍处于等待状态。该指南是一部未出版的候选纪录片。 Hyperforce 特定值和任何不受支持的路线将保持保留，直到提供商和帐户所有者确认正确的程序。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。