Salesforce可以通过不同的产品和路线发送邮件。在更改DNS之前，请确定哪个系统发送了消息以及哪个组织拥有其配置。 Sales Cloud 通知、Marketing Cloud 活动和外部中继不应被视为一种可互换的设置。
本指南重点介绍管理Salesforce平台工作流程 DKIM 设置中的按键。请遵循其他发送产品的相应产品文档。
将发送权限与消息验证分开
Salesforce当前的域验证规则和 DMARC 解决不同的问题。域验证在Salesforce发送工作流程中建立批准的域。 DMARC根据通过的一致身份验证结果评估收到的消息的可见发件人域。
有效的DKIM密钥可以满足Salesforce的发送域验证要求。 Salesforce还记录了授权域验证选项。该替代方案的存在并不意味着DNS所有权检查会创建一致的 DKIM签名 在一条消息上。
单独检查任何个人地址验证要求。记录实际路由、发件人地址、域验证状态和活动签名配置，而不是将它们折叠为一种绿色状态。
为目标域创建DKIM配置
在正确的组织中使用记录的DKIM密钥工作流程。选择目标域和支持的密钥配置，并使用不会覆盖其他发件人记录的不同选择器。
Salesforce生成主要和备用 CNAME 域的安排。发布帐户生成的名称和目标，而不是复制公共示例。候补人员参与提供者的轮换设计，不应作为重复人员被丢弃。
其当前说明要求为拥有的子域提供单独的DKIM密钥，并建议不要对拥有的域配置进行通配符匹配。检查确切的发送身份，而不是假设一个父域设置涵盖每个子域。
在变更请求中保留组织参考和生成的记录集。这些详细信息有助于区分生产、沙箱和单独的业务单元配置。
验证发布，然后激活
检查生成的权威答案 选择器 名称。检查DNS编辑器是否未两次附加域或更改记录类型。
等待提供商的发布流程和公共DNS要求得到满足，然后按照支持的激活步骤进行操作。保存的密钥配置和公开可见的CNAME是依赖项；两者都不能证明预期的出站消息正在被签名。
保留其他活动DNS记录和现有DMARC策略。添加Salesforce作为发件人不应默默地重置域范围的报告或更弱/更强的策略选择。
检查替代身份和替代路线
Salesforce记录了未经验证的域的替代发件人选项。如果启用，可见发件人可以使用选定的经过验证的组织范围地址；如果未选择任何选项，则记录的后备是组织或站点特定的sfcustomeremail.com地址。站点特定的设置可以覆盖组织范围的设置。显示名称和回复可以保持不变。诊断实际收到的地址，而不是假设用户输入的地址保持不变。
另请检查电子邮件中继或特定于产品的路由。下游系统可以更改验证哪个身份以及修改消息的位置。最终收到的消息是正在审查的路线的证据。
在综合示例中，团队通过所有权工作流程验证域并关闭票证。后来的警报仍然没有一致的品牌签名。缺少的证据是通过该警报的实际路径进行签名和接收，而不是组织控制DNS的另一个证据。
测试人们依赖的业务事件
执行重要工作流程的受控版本，例如案例通知或自动警报。检查原始收到的消息和受信任的接收者结果，将可见的发件人、 DKIM d= 和信封标识放在一起。
DMARC可以通过任一对齐 SPF 或对齐的DKIM 。记录哪条路径有效，以及如果中继更改消息或信封身份会发生什么情况。不要假设服务控制返回路径的SPF授权与品牌一致。
保持 结盟 诊断和与移交相关的发送者库存。完成意味着特定的产品、组织和工作流程使用预期的标识以及下一个操作员可以重复的证据。
跟踪已验证但未签名的路线
书面案例 SF-01 假定example.org具有经过验证的授权电子邮件域条目，但其DKIM密钥处于非活动状态，因为缺少备用CNAME 。预期发件人是cases@example.org ；不存在收到的消息、信封或签名结果。 Salesforce所有者和DNS所有者必须在测试案例通知路由之前协调生成的别名并激活正确的密钥。所有权验证并不能填补签名空白。未访问任何组织、配置、 DNS记录或案例消息。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。