WordPress 通常是创建消息的应用程序，而不是最终将消息发送给收件人的服务。插件名称或“已发送”通知无法识别评估的 IP SPF 或 a 中的域 DKIM签名。跨越 WordPress、其 运输 以及接收邮箱。
确定每个阶段的所有者
从事件开始：密码重置请求、订单通知或联系表单提交。记录创建消息的插件或代码路径、配置的发件人地址、传输插件（如果存在）以及它是否使用本地 PHP 邮件、远程SMTP还是提供商 API。 WordPress 的邮件手册解释说，插件可以用第三方服务替换默认发送路由。
通过授权管理检查配置，无需将凭据复制到票证中。记录服务名称、帐户或项目标签以及发送域，但将 API 机密和SMTP密码保留在证据文件之外。还要检查后备行为。插件可以为其主路由正确配置，而单独的作业或后备使用托管服务器。
不要将申请成功与交付混淆
WordPress 文档表明，真正的 wp_mail() 返回值意味着发送方法没有错误地处理了请求，而不是收件人收到了消息。同样，接受 API 调用的提供商会建立与最终交付不同的阶段。
将应用程序事件与传输或提供商标识符以及传递或退回事件（如果可用）相关联。使时间戳保持一致的时区。如果提供商没有该事件的记录，请在更改提供商的DNS之前调查应用程序和插件路径。如果它接受了事件但接收者拒绝了它，请收集完整的SMTP诊断和身份验证证据。
在实际发件人处配置身份验证
对于远程SMTP或 API 服务，请使用该服务的当前域身份验证流程。发布其生成的 DKIM TXT或 CNAME 准确记录并在需要时激活域。确定信封域以及产品是否支持自定义退回或 返回路径 领域。不要发明 WordPress 范围内的SPF包含； WordPress 不是一种通用的出站邮件网络。
对于托管服务器路由，请与主机或邮件管理员合作以确定真正的公共发送基础设施和支持的DKIM签名者。将网站的 IP 添加到SPF而不证明它发送邮件可能会授权错误的系统。在评估的信封域中维护一项适当的SPF策略并考虑查找限制。
为了 DMARC，在组织有权发送邮件的域下选择发件人地址。联系表格访客的地址通常属于 回复，而不是作为伪造的 From 身份。为组织的发件人域配置一致的身份验证路径，并与其他合法发件人协调策略。回复不建立DMARC 结盟.
完成综合事件跟踪
仅作为说明，未执行 WordPress 或提供商测试：
- 阶段：订单活动；证据标签示例：order-test-42；其内容：应用程序请求通知。
- 阶段：插件提交；证据标签示例：transport-event-42；它建立了什么：选定的传输处理请求。
- 阶段：提供商验收；证据标签示例：provider-message-42；它建立的内容：发送提供商接受了该事件。
- 阶段：外部收据；证据标签示例：已编辑的原始标头；它建立的内容：最终发件人、信封、 DKIM和DMARC结果。
假设传递的消息使用orders@example.com 、提供商拥有的信封域和传递的d=example.com签名。即使SPF未对齐， DKIM也可以提供对齐的DMARC身份验证。如果后备方案从未经信封域授权的托管 IP 发送未签名的邮件，则相同的应用程序事件可能会产生不同的结果。仅在批准的范围内故意测试后备。
留下可维护的交接
分配单独的应用程序、传输和DNS所有者。存储配置版本、生成的公共记录以及编辑成功和失败的测试证据。在插件升级、托管迁移、提供商更改、发件人地址更改或密钥轮换后执行密码重置和其他关键事件。监控实际的退回和失败，而不是依赖绿色 WordPress 状态。
停用时，仅在检查共享依赖项后禁用未使用的传输访问并删除过时的DNS授权。如果其他应用程序仍然使用该发件人，请勿仅仅因为某个插件被替换而删除该提供商的记录。
分离四个故障位置
使用事件跟踪来区分无应用程序事件、无传输提交、提供者拒绝和最终接收者失败。当阶段没有可靠的日志时，记录未知。不要从收件箱消息缺失或方法成功返回的最终收据中推断提供者拒绝。在整个切换过程中保留原始标识符，以便应用程序和邮件所有者调查同一事件。