将帐户参与与其他Salesforce电子邮件产品分开
Salesforce Account Engagement 有自己的域管理工作流程。首先确认消息是通过 Account Engagement（以前称为 Pardot）发送的，而不是核心Salesforce电子邮件或 Marketing Cloud Engagement。另一个Salesforce产品的DNS配方可以使用不同的控件，并且不应仅仅因为组织使用相同的供应商而导入。本指南涵盖帐户参与发送域验证、 DKIM 以及可选的支持辅助自定义返回路径。
列出帐户使用的每个业务部门、品牌和预期发件人域。包括由活动和自动化设置选择的实际发件人。不会为每个帐户参与路由自动配置用户邮箱地址中显示的域。指定营销所有者和DNS管理员在更改共享域的记录之前一起检查清单。
接受目标是具有一致的通过身份验证机制的受控接收消息。域名所有权验证、 DNS发布和绿色管理状态是有用的中间证据。没有任何证据可以单独证明特定活动使用了预期身份或接收服务器接受了其身份验证。
在编辑根DNS之前了解默认SPF路径
Salesforce's 帐户参与DNS指导 表明帐户参与邮件通过 SPF 通过其受控的发送基础设施，并且不需要客户针对默认设置更改SPF 。不要仅仅因为产品名称出现在组织的根域中就添加通用Salesforce SPF包含 DMARC 报告。首先确认实际路线并评估身份。
SPF验证SMTP 邮件来自 身份，单独处理 HELO， 在下面 RFC 7208。其结果不同于 结盟 与可见的From。成功的提供商域SPF检查可以与未对齐的SPF共存。更改不同域的策略不会更改邮件使用的信封域。
保留组织其他服务所需的SPF策略。如果单独授权的自定义设置需要更改策略，请查看该所有者的一项完整策略，包括嵌套的 DNS 查询术语和协议查找限制。不要创建第二个 SPF记录 或删除不相关的发件人以便为未经验证的要求腾出空间。
将所有权和DKIM验证为单独的记录
使用域管理来识别预期的电子邮件发送域及其预期的DNS条目。这 DNS指导 区分域的验证密钥和域密钥。验证值建立发送的所有权； DKIM值支持消息签名。在工作表中保留这两个目的，而不是处理任何 TXT记录 包含Salesforce值作为可互换的证据。
从实际帐户复制值。在进行DNS更改之前，保存完整的记录所有者、类型、值和说明日期。检查另一个帐户参与帐户或不同的服务是否已依赖于同一所有者。不要覆盖冲突的记录、重复使用其他客户的值或更改 选择器 一个发明的名字。当帐户安排发生冲突时，请求支持人员提供支持的解决方案。
保持电子邮件发送域与跟踪器域不同。 Salesforce明确警告不要对这两个功能使用相同的域。品牌跟踪主机名与发件人域不同，即使两者共享父域也是如此。单独跟踪库存依赖性，以便身份验证工作不会无意中更改资产 URL 或活动链接。
通过记录的工作流程发布 DomainKey
Salesforce's DKIM实施说明 需要帐户参与管理员角色。在 Lightning 应用程序中，打开帐户参与设置，然后打开域管理。在备用帐户参与界面中，记录的起点是管理员。在电子邮件发送域下，打开所选域的预期DNS条目并复制 DomainKey 值以作为TXT发布。
使用该帐户和域显示的所有者和值。目前的文章说添加记录后最多允许 24 小时签名生效。将其视为提供商计时指南，而不是保证每个DNS缓存或接收器都会在同一时刻更新。记录发布时间并等待预期状态，然后再判断新的测试。
确认公共DNS答案，包括确切的完全合格所有者。 DNS编辑器有时会将区域名称附加到主机字段，从而在输入全名时创建重复的后缀。检查结果答案而不是相信输入表单。保存任何域管理错误及其详细信息，以便支持人员可以调查实际的故障而不是解释的状态。
决定是否需要自定义返回路径
Salesforce's DMARC支持文章 将对齐的DKIM描述为正常DMARC路径，并解释默认情况 返回路径 域与可见的 From 不一致。它还记录了支持辅助的自定义返回路径请求。所述限制是每个业务单位一个固定的自定义返回路径域，而不是为每条消息选择的可变域。
在请求此选项之前，请确定业务需求。需要对齐SPF和DKIM组织应在支持下评估实际的域排列和对齐模式。发送不相关品牌的业务部门不应假设一个固定的返回路径可以与每个“发件人”域保持一致。保持该设计问题处于开放状态，直到观察到的身份和支持的配置解决它。
从支持案例中获取准确的DNS记录，并让DNS所有者检查冲突和依赖性。本文不提供通用的自定义返回路径目标或激活开关。发布猜测的记录或复制其他产品的跳出域配置可能会破坏工作路由而不满足要求。
通过实际的消息流测试所选的发送者
通过每个实质上不同的发送域和业务单元路由发送无害的受控消息。使用与计划的活动或自动化相同的发件人选择。记录活动参考、消息 ID、UTC 时间和外部测试收件人。如果预览或测试功能使用与生产不同的路径，请在将其视为代表性证据之前解决该差异。
在受信任的接收系统中，捕获发件人、 Return-Path以及所有DKIM签名域和选择器。 RFC 6376 定义用于查找公共验证密钥的 d= 和 s= 值。将观察到的签名域与配置的发送域进行比较。 DNS记录可能是正确的，但邮件仍然使用意外的发件人或其他路由。
申请 RFC 9989 以实际结果为准。 DMARC可以通过传递对齐 DKIM签名 或通过对齐的SPF 。记录提供结果的机制以及应用的对齐模式。将SPF身份验证、 SPF对齐、 DKIM身份验证和DKIM对齐保留在单独的字段中。这可以防止单个绿色状态隐藏未经测试的需求。
对失败的边界进行故障排除，而不是更改每个控件
如果发送域未经验证，请将其验证密钥和确切的DNS所有者与预期DNS条目进行比较。如果在预期激活期后DKIM丢失，请确认所选的“发件人”域和帐户，然后检查“域管理”错误。如果签名失败，请验证选择器和公共值，并检查签名后更改消息的任何下游系统。
如果DMARC在SPF通过时失败，请调查对齐以及是否为该发件人配置了对齐的DKIM 。不要将默认SPF成功视为DMARC成功的承诺。如果涉及自定义返回路径，请将观察到的信封标识与固定业务部门设置和支持提供的说明进行比较。保留有代表性的失败消息以供诊断。
将组织的DMARC政策和报告目标保留在其现有所有权之下。 Salesforce文章描述了需要外部DMARC监控，而不是收集这些信息的 Account Engagement 故障报告。 DNS身份验证工作不应默默地取代报告目的地或降低不相关发件人之间的执行力度。与邮件和安全所有者单独审查任何拟议的策略更改。
帐户参与域工作表
- 帐户、业务部门、品牌和发送工作流程：____。
- 选择的发件人地址和配置的电子邮件发送域：____。
- 单独的跟踪器域及其现有依赖项：____。
- 来自预期DNS条目的验证密钥和DKIM记录引用：____。
- 公共DNS答案、发布时间及管理状况：____。
- 默认或支持辅助的自定义返回路径设计：____。
- 自定义返回路径限制和相关支持确认：____。
- 测试消息 ID、UTC 时间、发件人、 Return-Path和DKIM身份：____。
- 可信的身份验证结果和一致的DMARC机制：____。
- 例外情况、监控所有者和批准的恢复：____。
无需对齐即可实现SPF成功的虚构示例
仅虚构的书面案例：AE-01 假设业务部门 North 发送为news@example.org ，业务部门 South 发送为news@example.net 。 bounce.example.org下提议的固定自定义返回路径可能与宽松SPF对齐下的第一个路径对齐，但不能假定与不相关的第二个路径对齐。 DKIM签名和SPF结果仍然未知，因此这两个路由都没有断言的DMARC判决。营销和邮件所有者应将业务部门设置分开，并在请求任何根SPF编辑之前验证每个选定发件人域的一致DKIM 。所有的身份和安排都是发明的；没有支持案例、 DNS查询或消息被执行。
将完成情况与现场证据联系起来
记录的工作流程不会验证真实租户的权限、生成的值或自定义返回路径功能。这些帐户检查、实时DNS和标头验证、目视审查和 SME 人工批准仍然悬而未决。本指南尚未发布，不得作为组织的活动在生产中经过验证的证据。
将传递的消息与执行准备情况分开
RFC 9989第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。