选择说明之前确认 CMS 部署
Optimizely CMS 创建应用程序消息，但配置的传输发送它们。首先记录处理受影响工作流程的 CMS 版本、托管模型、环境和邮件集成。不能假定在 DXP 上运行的 CMS、自托管安装和具有自己的第三方中继的应用程序共享一个 SPF 或者 DKIM 配置。 Optimizely Campaign 是一个单独的产品，不得借用其营销邮件域记录用于 CMS 通知。
本指南检索的第一方 DXP 电子邮件服务器页面标记为 DXP for CMS 12 和 Commerce 14。它记录了云 交易电子邮件 服务、SendGrid 支持的SMTP配置和支持辅助的域身份验证过程。本文使用该路线作为其具体实现分支。适用于其他 CMS 版本、托管层或自定义集成需要相应的当前文档和部署证据。通用目录标签 Optimizely CMS 比此处建立的配置范围更广泛。 DXP 电子邮件服务器配置
在编辑配置之前，请指定应用程序所有者、部署操作员、邮件管理员和DNS所有者。商定哪个工作流程将证明成功：项目通知、内容批准消息或其他明确配置的应用程序电子邮件。使用合成内容和受控收件人。营销通讯并不能代替 CMS 通知测试，因为这两种产品具有相同的供应商名称。
跟踪从应用程序事件到中继的消息
将路线分解为事件创建、应用程序调度、 SMTP提交、提供者传递和接收者身份验证。记录每个阶段可用的证据。如果应用程序从不生成或发送通知，则编辑SPF无法创建通知。如果SMTP拒绝凭据，则邮件尚未到达收件人评估的阶段 DMARC.
Optimizely 的 CMS 13 项目文档单独描述了通知发送，并表示必须为电子邮件通知配置SMTP设置。支持实际安装CMS 13时检查trigger和dispatch stage；它不能确定 CMS 12 部署具有相同的作业默认值，也不能确定 DXP SMTP示例应用不变。将配置说明与已安装的版本相匹配，而不是混合版本化的片段。 CMS 13 项目通知
对于每个环境，将有效的运行时配置与部署期间可能被覆盖的源文件区分开来。暂存成功可能与由于缺少设置或不同的发件人地址而导致的生产失败共存。通过正常的工程流程收集经过清理的设置和应用程序日志。不要在证据数据包中暴露SMTP凭据、API 密钥或不相关的生产机密。
通过受控部署配置记录的 DXP 传输
DXP 指南表示，标准配置转换不会自动应用电子邮件配置。它描述了通过 DXP 管理门户获取电子邮件服务凭证并向应用程序提供SMTP设置。其示例包括应用程序通知身份设置以及传输设置。使用已部署版本和环境支持的配置机制，并查看生成的有效值。 DXP 电子邮件服务器配置
将凭证创建、存储和轮换视为单独的受控安全操作。如果已批准的工作凭证已存在，则本指南不需要新的凭证。切勿将机密粘贴到公共文章、存储库示例、 DNS记录或支持屏幕截图中。请参考经批准的秘密商店和负责的运营商。确认测试时部署日志和错误报告不会打印凭据。
记录的 DXP 服务用于自动交易网站通信。该指南将需要其他SendGrid功能（例如使用自己的自定义 HTML 模板）的客户引导至单独订阅的帐户或其他SMTP提供商。确认预期用途，而不是假设对 DXP SMTP访问就是对客户管理的SendGrid帐户的无限制访问。单独的帐户有自己的所有权和域身份验证程序。
为每个发送域请求身份验证
对于记录的 DXP 路由，请联系 Optimizely 与发送域以获得激活发件人身份验证的帮助。该指南还指出，每个邮件发送域都必须请求DKIM ，并且需要额外的DNS记录。在发布任何内容之前，获取环境的准确记录集和激活计划。没有通用性 选择器, CNAME 目标或私钥可以从产品名称中派生出来。 DXP 域和DKIM配置
列出相关通知使用的每个可见的 From 域。如果多站点应用程序或单独配置的工作流程使用不同的域，请询问支持人员哪种身份验证配置涵盖每个域。不要假设验证主要公司域会自动激活每个子域或备用品牌。记录在DNS发布后必须确认发送方激活的人员。
DXP 页面包含示例SPF策略。将它们视为文档示例，而不是生产领域的完整规定。确定实际的信封所有者、保留其他授权发件人并维护一项有效的SPF策略。在合并授权之前评估递归查找限制。如果配置的传输与记录的 DXP 服务不同，请改为获取该传输自己的当前说明。 SPF RFC 7208
使用提供的类型在确切的所有者处发布每个提供的DKIM记录。在计划的过渡期间保留活动选择器，在保存之前解决CNAME冲突，并将私钥保留在DNS之外。查询权威服务器以验证结果名称和值； DNS编辑器预览是不够的。仅当实际传出消息使用其相应的签名身份时，公共记录才支持验证。 DKIM RFC 6376
保持发件人身份和DMARC政策协调一致
在测试前商定预期的可见发件人地址。正确的SMTP主机名和工作凭据并不能证明应用程序使用批准的发件人域。与传输配置分开记录有效的通知标识和任何应用程序级覆盖。检查回复处理，以便在没有业务决策的情况下收件人不会被定向到无人值守的邮箱。
检查可见域的当前DMARC策略并保留其批准的执行， 结盟 和报告配置。当至少一个传递的SPF或DKIM身份在适用模式下对齐时， DMARC会成功。提供商拥有的签名域可以通过加密验证，而无需与组织的可见发件人域保持一致。在检查支持的发件人身份验证路由之前，请勿通过削弱整个域的策略来做出响应。 DMARC RFC 9989
应用程序连接、提供商身份验证和收件箱放置是单独的验收结果。表明邮件已提交的 CMS 日志并不是来自最终邮箱的收据。通过DMARC收到消息可能仍会因其他原因而被过滤。在变更报告中保留这些区别，以便成功的一层不会隐藏其他地方未解决的问题。
可重复使用的 CMS 和 DXP 路线工作表
为每个部署环境和实质上不同的发送身份完成单独的副本。
- CMS版本、托管模式、项目和环境：______。
- 确切的工作流程、合成触发器和预期接收者：______。
- 配置来源、部署修订和有效运行时设置：______。
- 仅限运输提供商、帐户所有者和批准的秘密参考：______。
- 可见发件人、显示名称、回复目的地和信封期望：______。
- 确认 DXP 适用性和每个发送域的支持案例：______。
- 已发布的DNS所有者、类型、值和激活要求：______。
- 现有SPF和DMARC政策以及批准的变更集：______。
- 权威答案、查询次数和提供商验证状态：______。
- 调度、 SMTP提交和提供商交付证据：______。
- 收到的消息来自信封、所有DKIM d=/s=对和可信结果：______。
- 回滚部署、 DNS恢复计划和人工接受：待定。
生产通知故障的虚构诊断
这个例子是虚构的。团队在暂存阶段成功测试了批准通知并部署了应用程序。生产消息使用不同的可见 From 域。 SMTP提交成功，但独立接收方报告了与该生产域不一致的有效提供商签名。该团队建议将 Campaign DKIM目标复制到DNS中，因为它也属于 Optimizely。
提议的诊断将有效生产身份与 DXP 支持请求涵盖的域进行比较。在这种情况下，仅包括暂存标识。纠正计划是请求生产发送域支持的身份验证配置，发布已发布的记录并重新测试实际的审批工作流程。借用营销活动记录并不能证明 DXP 签名者使用了该记录。这是一个可行的示例，而不是实时测试或有关任何客户部署的断言。
在发生变化的层恢复
如果应用程序停止提交消息，请在恢复DNS之前比较部署和传输设置。如果域验证失败，请将支持发布的所有者与权威答案进行比较。如果身份验证通过但传送失败，请检查提供商和收件人的响应，而无需扩大发件人的权限。在重试之前保留证据，以便识别重复的通知。
回滚应恢复受影响较小的部署或DNS更改，而不是轮换每个凭据或重置整个区域。仅在邮件所有者确认没有活动或排队的路由需要它们后，才停用被取代的选择器。已建立记录的 DXP 分支，但更广泛的 CMS 版本适用性、特定于租户的设置、支持发布的值、实时DNS 、收到的消息、视觉审查和 SME 人工批准仍然悬而未决。本指南没有更改应用程序配置、凭据、 DNS记录或实时工作流程。
确保传输安全远离复制的示例
公共页面混合了配置文件示例，并包含禁用 SSL 的代码设置。本文不批准该设置或版本不匹配的代码片段。让部署所有者确认实际运行时支持的传输和TLS行为，而无需公开凭据。在虚构的情况下，仅提供者签名并不能确定未指定的SPF结果。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。