分离 CRM 的交付路径
CRM 可以通过自己的基础设施发送或提交给单独配置的邮箱提供商。从路线清单开始：一对一的 CRM 消息、自动化工作流程、案例回复和系统通知。记录每个的预期发件人身份以及负责其配置的管理员。不要推断一条成功的消息就涵盖了所有这些。
Vtiger 的电子邮件设置文档将传出服务器配置与发件人身份验证域区分开来。它还指出系统电子邮件将继续通过 Vtiger 服务器，无论配置的传出服务器如何。这种区别应该驱动测试矩阵，而不是假设选择外部服务器会移动每条消息。 Vtiger 电子邮件设置.
使用租户的身份验证值
打开设置 > 配置 > 电子邮件设置，然后确定发件服务器和发件人身份验证配置。对于 Vtiger 管理的域身份验证，获取 SPF 和 DKIM 为您的域提供的记录，将它们发布到权威DNS上，然后返回到 Vtiger 进行验证。将租户的记录值与变更请求一起保留。 发件人身份验证域.
公共身份验证文章包含以 -al 结尾的格式错误的SPF示例。不要部署它。使用当前帐户提供的配置并独立验证完成的策略；无效的示例是不允许猜测替换值。如果租户的指示不明确或与其记录的路由冲突，请在编辑DNS之前获得澄清。 Vtiger认证文章.
发布时不会丢失其他发件人
备份现有的SPF 、 DKIM和 DMARC记录。将所需的SPF机制合并到评估域的单个现有SPF策略中，保留批准的发件人和预期的终端限定符。检查完整的评估树，而不仅仅是计算可见的包含内容。在提供的位置发布帐户特定的DKIM公共记录 选择器 名称，并检查公共答案是否有意外重复的域名后缀。 SPF.
对于单独选择的SMTP提供商，请使用该提供商的域身份验证说明。不要仅仅因为CRM是合成界面就添加Vtiger权限。还要避免假设更改的回复会更改经过身份验证的发件人身份。回复路由和 DMARC 结盟 回答不同的问题。
使用无害事件测试每个工作流程
使用受控收件人和合成 CRM 记录。不要仅仅为了测试身份验证而触发真实的客户提醒或支持回复。捕获 CRM 事件时间、可用消息 ID、配置的路线和收到的原始消息。
- 工作流程：一对一CRM消息；比较内容：选择的发送服务器和实际信封；未能进行调查：路线与预期不同
- 工作流程：自动化工作流程；比较内容：来自身份和所有DKIM签名；调查失败：配置的密钥未涵盖发件人域
- 工作流程：案例回复；比较什么：批准者和单独的回复；调查失败：将回复路由误认为是身份验证
- 工作流程：系统通知；比较什么：观察到的 Vtiger 路由和发送者身份；未能调查：假设外部SMTP设置普遍适用
这是验收设计，而不是执行证据。对于每个原始文件，使用受信任的接收器结果将成功的SPF评估与其信封域以及每个成功的DKIM结果与其 d= 域配对。将这些身份与有效DMARC对齐模式下的可见 From 进行比较。一种对齐传递方法可以满足DMARC ；单独传递一个不相关的提供者签名是不行的。 DMARC.
解决差异并保留恢复
如果专家组无法验证 一个记录，将其确切的主机名、类型和值与权威DNS进行比较。如果DNS正确但工作流仍未签名，请检查该工作流的路由和发件人域，而不是轮换不相关的密钥。对于外部SMTP拒绝，请保留服务器响应并检查所选帐户允许的发件人身份。对于系统电子邮件，根据记录的异常确认观察到的身份，而不是强制对其进行外部配置。
如有必要，仅暂停受影响的自动化，并恢复其之前批准的发件人或传输设置。保持其他工作路线活跃。修复后，重复失败的案例和已知良好的控制案例。保存经过编辑的证据、 DNS快照和所有者批准，以便可以根据基线检查以后的 CRM 或邮箱提供商更改。该草案仅使用公共文档；未执行 CRM 租户、消息发送或DNS更新。
确认提供商边界
当前的设置指南还要求在保存设置和发送邮件之前验证配置的发件人和回复地址。地址所有权验证与域DNS验证和DMARC对齐是分开的。在更改DNS之前查看外发电子邮件失败详细信息。其认证文章包含过于简化的DKIM身体覆盖语言；使用RFC 6376 ，而不是声称普通签名可以简单地省略正文。配置的DMARC状态不是收到消息的结果。
完成一个虚构的诊断案例
仅虚构书面案例：VT-01 假定一对一 CRM 消息使用 From support@studio.example并通过外部SMTP传递带有d=studio.example的DKIM 。系统通知使用不同的提供者路由；其发件人、信封和签名尚未被捕获。第一条消息无法关闭系统通知行。 CRM 所有者必须收集该单独的受控通知并验证其实际身份是否为预期身份。此案例没有测试任何帐户、 DNS 、CRM、发票、活动或交付。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。