识别DreamHost实际发送路由
本指南适用于 DreamHost 托管的邮件，而不是附加到在 DreamHost 注册的域的每个应用程序或邮件服务。注册、权威DNS托管和出站邮件传输是不同的事实。单独盘点网络邮件、桌面邮件客户端、网站联系表格和新闻通讯插件。域的普通邮箱可能使用 DreamHost SMTP ，而其网站则使用 PHP 邮件在本地发送，这会改变签名行为。
DreamHost 表示，通过其邮件服务器使用网络邮件、邮件客户端或SMTP表单发送的邮件会自动进行 DKIM 签名。其文档明确排除不使用SMTP网站邮件，包括通常的 sendmail 或 PHP 邮件路由。已发布的密钥无法自行签署消息。在编辑DNS以修复丢失的签名之前，请检查应用程序是否确实通过经过身份验证的邮件服务器提交。
找到并发布帐户DKIM记录
对于 DreamHost 托管的邮件，DreamHost 创建并管理 DKIM 使用其电子邮件服务的域和子域的记录。打开管理网站，使用域的三点菜单并选择DNS设置。在网格视图中，菜单出现在域下方；在列表视图中，它显示在右侧。检查 TXT记录 名称中包含_domainkey 。该文档说明了 dreamhost。 _domainkey 选择器 和 2048 位 键，但您的域的值必须来自您自己的面板。
如果权威 名称服务器 在 DreamHost 外部，请将该帐户的完整记录复制到实际的DNS服务中。 一个记录 当另一个提供商具有权威性时，DreamHost 面板中可见的内容不会建立公开发布。将所有者名称调整为该编辑器的相对名称或完全限定名称约定，并检查生成的公共名称。保留公钥，而不在密钥数据中插入空格。不要发布帮助文章中打印的示例密钥。
不同活动服务使用的选择器必须保持不变。不同的服务可以发布不同的选择器，但每个签名必须在其 d= 域下解析自己的 s= 选择器。在假设消息使用示例选择器之前，请确认消息的实际签名。如果域通过另一个提供商发送，请获取该提供商的签名说明，而不是期望 DreamHost 密钥来验证其流量。
仔细检查默认和自定义SPF
DreamHost 为其邮件服务记录了此自动策略： v=spf1 mx include:netblocks.dreamhost.com include:relay.mailchannels.net -all 。将其视为记录的默认值以与您当前的配置进行比较，而不是现有多提供商策略的通用替代品。确认哪些主机和信封域实际需要授权。 SPF 单独评估子域，因此 apex 记录不会自动覆盖单独的信封子域。
添加自定义 SPF记录 在 DreamHost 中删除其默认记录。如果 DreamHost 仍然是授权发件人，请在检查活动路由和查找依赖项后在组合自定义策略中保留适当的权限。该文档还表示，删除自定义SPF记录会导致默认值自动返回。该行为在恢复过程中很重要：删除不一定是删除SPF授权，并且恢复的默认值可能会忽略其他合法服务。
在外部权威DNS处，管理那里的相关策略。为所有者保留一份适用的SPF TXT政策。不要添加第二个来保留默认值，并且不要假设历史示例中显示的每个包含都是永远必要的。更改后和任何回滚后重新检查已发布的策略，包括自动恢复记录的影响。
在传输层修复网站邮件
对于使用 sendmail 或 PHP 邮件的联系表单或 WordPress 插件，如果预期路由是 DreamHost 托管的邮件，则首选受支持的经过身份验证的SMTP配置。验证表单的真实输出，而不仅仅是插件的连接测试。触发实际工作流程，保留收到的消息并确认签名者和可见的 From 身份。应用程序可以成功连接，但在生产中仍然使用不同的发件人地址。
DreamHost 还记录了在具有管理员用户的专用服务器或 DreamCompute 上自行管理的DKIM安装，但表示它不支持手动安装的软件。这是一个单独的系统管理项目，而不是相当于托管SMTP路由的复选框。不要将其作为未经审查的联系表单解决方法引入。如果您选择它，则需要一个单独的密钥、签名、更新和恢复操作计划。
验证发送身份，而不仅仅是仪表板
绿色设置指示器仅确定产品执行的检查。要接受，请通过实际工作流程将受控消息发送到您可以检查其收到的标头的邮箱。保留原始消息而不是成功DNS查找的屏幕截图。记录可见的From域，接收系统显示的SMTP信封域，每个 DKIM签名'sd= 签名域和 s= 选择器，以及接收系统的 Authentication-Results。不要仅仅因为发件人插入了Authentication-Results字段而信任该字段。
SPF验证信封身份，而不是自动验证可见的发件人地址。 DKIM验证其签名域的签名。 DMARC 需要与适用的可见域下的通过路径对齐 结盟 模式。提供商拥有的信封可以通过SPF ，但不会为您的品牌产生一致的SPF 。相反，即使SPF未对齐，有效的对齐DKIM签名也可以提供通过的DMARC路径。更改DNS之前检查实际身份。
使用此说明性接受案例，而不是作为有关提供商默认设置的声明：消息包含learning@example.com 、信封bounce@vendor.example.net以及经过验证的DKIM签名（ d=example.com.仅vendor.example.net的SPF成功与example.com不一致； d=example.com的有效签名提供精确的DKIM对齐。如果接收方报告无效签名，则该示例不再具有经过的对齐路径。记录身份验证结果及其适用的域。
按固定顺序诊断故障
首先确认为确切域委派的名称服务器是您编辑的服务器。向权威服务器查询预期的所有者名称和记录类型。将他们的答案与帐户提供的值进行比较，检查意外的域后缀重复、丢失的选择器标签、截断的键和CNAME冲突。只有在权威答案正确后，您才应该研究递归缓存或等待较早的 TTL 过期。没有单一的保证全球传播的最后期限。
接下来在失败的路由上重复消息测试。 Web 应用程序可以使用与人类邮箱不同的传输方式，并且成功的预览并不能证明生产通知使用相同的身份。如果DNS正确但缺少签名，请调查发送传输和产品配置，而不是添加不相关的SPF权限。如果身份验证通过，但邮件被放入垃圾邮件中，请保留标头并单独调查信誉、内容和收件人处理。身份验证不保证收件箱的放置。
变更控制和完成证据
在进行更改之前，保留以前的记录集、批准的新值、域所有者、每个受影响工作流的业务所有者以及特定的恢复决策。切勿在同一所有者处创建第二个SPF策略来添加发件人。查看一项组合策略及其 DNS 查找依赖性；不相关的TXT记录可以共存，但多个候选SPF策略是错误的。不要覆盖其他发件人的选择器。不要削弱整个域的DMARC策略来掩盖失败的集成。
接受需要权威的DNS证据、产品验证以及每个范围内发送路由的接收消息身份记录。在工作流程需要的地方单独测试回复。这些是建议的检查，而不是已完成的测试：本指南基于保留的文档和综合推理，没有实时租户更改、 DNS测量或传递的消息结果。人类所有者必须审查证据并批准任何生产部署。保持现有工作路由可用，直到演示替换为止，并且仅在确认没有剩余依赖项使用它们后才删除过时的权限。
在更改策略之前评估传输不匹配
对于书面案例 DH-01，假设来自help@example.com的员工网络邮件具有可信传递的DKIM签名d=example.com, s=dreamhost.网站表单使用 PHP 邮件，并且没有观察到DKIM签名；其SPF结果未知。第一条路线具有规定的对齐路径，而第二条路线仍未解决，而不是自动使每种机制失败。要求网站所有者验证支持的SMTP配置并在授权测试中触发无害的表单事件。面板密钥不提供缺失的签名。没有测试或更改实际的消息、插件或DNS记录。
为了进行恢复，请在删除任何自定义策略之前将当前SPF记录与批准的基准进行比较。在此提供商记录的行为中，删除将恢复其默认值；这不一定与恢复之前完整的多发送者策略相同。
保留执行边界
对于发布p=reject, RFC 9989第 7.4 节要求有效的DKIM而不仅仅是SPF ，并就间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。