文章
文章文档网址导航

网站迁移后邮件总进垃圾箱？SPF、DKIM、DMARC 与 PTR 记录配置指南

网站迁移后邮件频繁进入垃圾箱，通常与发信 IP、SPF、DKIM、DMARC、PTR 和 HELO 配置变化有关。本文提供从 DNS 到邮件头的完整排查与验收方法。

网站迁移完成后，页面访问、数据库和 HTTPS 都正常，注册验证码、订单通知、密码重置邮件却突然开始进垃圾箱。这类问题通常不是 WordPress 或邮件模板单独造成的，而是迁移改变了实际发信链路：出口 IP 换了，SMTP 服务商换了，DNS 里还留着旧授权，或者新服务器使用了不匹配的主机名。

排查时不要只盯着“邮件能不能发出去”。收件服务器还会检查发信 IP 是否得到域名授权、邮件签名是否有效、可见发件人与认证域名是否对齐，以及 IP 的反向解析是否可信。下面按迁移后的实际顺序，把 SPF、DKIM、DMARC、PTR 和邮件头检查串起来。

网站迁移后邮件总进垃圾箱？SPF、DKIM、DMARC 与 PTR 记录配置指南

先确认邮件究竟从哪里发出

同一个网站可能同时存在多条发信路径：服务器本机的 Postfix、主机商提供的 SMTP、企业邮箱、第三方事务邮件平台，甚至某个插件自带的 API。迁移前后如果路径发生变化，旧 DNS 记录自然无法替新系统背书。

先记录以下信息：

  • 用户看到的 From 地址，例如 notice@example.com
  • 邮件头里的 Return-Path，也就是退信域名
  • 实际连接的 SMTP 主机或邮件 API 服务商
  • 对外发信的公网 IP
  • SMTP 会话使用的 HELO/EHLO 主机名
  • 当前生效的 DKIM selector

不要用网站服务器的公网 IP 进行猜测。如果网站通过第三方 SMTP 发信，收件方看到的是第三方邮件节点的 IP，而不是 Web 服务器 IP。最直接的办法是向 Gmail、Outlook 等测试邮箱各发一封邮件，然后查看完整邮件头中的 Received、Return-Path、Authentication-Results 和 DKIM-Signature。

修正 SPF：只保留一条，并授权新的发信源

SPF 用来说明哪些服务器可以代表某个域名发送邮件。迁移后最典型的问题是新 IP 没有加入 SPF，或者 DNS 中并存两条 v=spf1 记录，导致验证出现永久错误。

假设网站改为从固定 IP 和第三方服务商共同发信，记录可能类似：

v=spf1 ip4:203.0.113.10 include:_spf.mail-provider.example -all

这里的 IP、域名和 include 都只是示例，必须替换为邮件服务商实际提供的值。修改时注意：

  1. 一个域名只能发布一条 SPF 记录。多个发信源应合并到同一条记录中。
  2. 删除已经停用的旧 IP 和旧服务商授权，避免授权范围越来越大。
  3. SPF 中会触发 DNS 查询的机制存在 10 次查询上限。层层嵌套 include 很容易超限。
  4. 尚未确认全部发信源时，可暂用 ~all 观察；确认无遗漏后再改为更严格的 -all。
  5. SPF 检查的通常是 Return-Path 对应域名，不一定是用户看到的 From 域名。

查询当前记录：

dig +short TXT example.com

看到两条以 v=spf1 开头的结果时，不要简单删除其中一条，应先把仍在使用的授权项合并，再移除重复记录。

启用 DKIM：确认签名与 selector 对得上

DKIM 会给邮件正文和部分头部字段添加数字签名，收件服务器再通过 DNS 中的公钥验证邮件是否被篡改。迁移到新邮件平台后，旧 selector 往往还在，但新平台使用的是另一把密钥。

DKIM 公钥通常发布在以下位置：

selector1._domainkey.example.com

记录值通常以 v=DKIM1 开头：

v=DKIM1; k=rsa; p=...

具体 selector 和公钥必须从当前邮件服务商后台复制，不能照搬示例。配置后先查询 DNS：

dig +short TXT selector1._domainkey.example.com

再发一封测试邮件，检查 DKIM-Signature 中的 d= 和 s=。其中 d= 是签名域名，s= 是 selector。两者拼成的 DNS 地址必须能查到对应公钥，邮件头中的验证结果应显示 dkim=pass。

如果使用 CNAME 委托 DKIM，也要检查目标记录是否存在。只在控制台点击“启用 DKIM”，但 DNS 委托没有完成，签名仍然不会通过。

部署 DMARC：先观察，再逐步收紧策略

DMARC 不会代替 SPF 或 DKIM。它关心的是认证通过后，认证域名是否与用户看到的 From 域名对齐。一般来说，只要对齐的 SPF 或对齐的 DKIM 有一个通过，DMARC 就可以通过；实际部署仍建议两者都配置，避免单条认证链路故障时完全失去保护。

初次部署可从监控策略开始：

_dmarc.example.com
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100

这个示例使用严格对齐。若企业当前存在子域发信、第三方群发或复杂退信域名，严格对齐可能暴露更多历史问题。正式使用前应根据邮件服务商建议决定 adkim 和 aspf 采用严格还是宽松模式。

推荐的上线顺序是：

  1. 先用 p=none 收集报告，盘点所有真实发信源。
  2. 修复报告中的 SPF、DKIM 和域名对齐失败。
  3. 小范围改为 p=quarantine，观察正常邮件是否受影响。
  4. 所有业务邮件稳定后，再评估 p=reject。

查询 DMARC：

dig +short TXT _dmarc.example.com

rua 邮箱会收到聚合报告，内容通常是 XML。它更适合确认哪些 IP 在冒用或代表域名发信，不是普通退信通知。报告邮箱也要有足够容量，并做好自动解析或归档。

配置 PTR，并让正向解析与 HELO 保持一致

PTR 是发信 IP 的反向 DNS 记录。它通常不能在域名 DNS 面板中自行添加，而要由该 IP 的持有者设置，也就是云服务器、独立服务器或邮件服务商。

比较稳妥的关系是：

203.0.113.10 -> mail.example.com
mail.example.com -> 203.0.113.10

同时让邮件服务器在 HELO/EHLO 中使用 mail.example.com，避免出现 localhost、内网主机名、临时云主机域名或与 PTR 完全无关的名称。

验证方法：

dig -x 203.0.113.10
dig +short A mail.example.com

第一条应返回邮件主机名，第二条应解析回同一个公网 IP。这种正反向一致通常被称为 FCrDNS。它不是 SPF、DKIM、DMARC 的替代品，但缺失或明显不一致会削弱收件方对自建邮件服务器的信任。

如果使用共享 SMTP 或 SaaS 邮件平台，PTR 通常由平台统一管理，不应要求它指向自己的域名。此时重点检查平台提供的 SPF、DKIM 和自定义退信域名配置。

等待 DNS 生效后，用邮件头做最终验收

DNS 面板显示“保存成功”不等于全球解析已经更新。受 TTL 和递归 DNS 缓存影响，修改可能需要一段时间才能完全生效。不要在记录刚保存后连续改来改去，否则很难判断测试命中了哪个版本。

建议分别通过本地 DNS、公共 DNS 和服务商检测工具查询，并向不同邮箱服务商发送真实测试邮件。重点查看类似结果：

spf=pass
dkim=pass
dmarc=pass

还要核对：

  • SPF 验证的域名是不是预期的 Return-Path 域名
  • DKIM 的 d= 是否与 From 域名对齐
  • DMARC 结果是否通过，而不只是 SPF 或 DKIM 单独通过
  • 最早一层公网 Received 是否显示预期发信 IP
  • HELO/EHLO 名称与 PTR、A 记录是否一致

不同收件服务商展示邮件头的方式不同，但判断逻辑相同。不要只看页面上的“已通过身份验证”图标，完整头部才能说明问题出在哪一层。

四项认证都通过，为什么仍然进垃圾箱

SPF、DKIM、DMARC 和 PTR 解决的是身份与基础可信度问题，并不保证每封邮件进入收件箱。认证全部通过后，仍要检查以下因素：

  • 新 IP 没有历史信誉，迁移后发送量突然增大
  • IP 曾被其他租户滥用，已有较差信誉或黑名单记录
  • 用户投诉率、退信率或无效地址比例过高
  • 邮件列表未经确认，长期不清理不活跃地址
  • 标题和正文过度营销，链接域名与发件域名关系混乱
  • HTML 结构异常、只有图片没有文本，或附件行为可疑
  • 订单、验证码与营销邮件共用同一发信域和同一 IP

迁移后应逐步恢复发送量，不要让一台新服务器在短时间内发送远高于历史水平的邮件。事务邮件与营销邮件最好拆分子域、通道和信誉管理，退订、退信处理也要正常工作。

WordPress 网站迁移后的常见遗漏

WordPress 本身默认调用 PHP 邮件函数，主机迁移后可能直接改用新服务器本地 MTA。即使页面和数据库原样迁移，发信身份已经不同。更稳妥的做法是使用可靠 SMTP 或事务邮件插件，并明确配置发件地址、Return-Path 和认证方式。

排查插件时注意以下细节：

  • SMTP 端口、防火墙和加密方式是否与服务商要求一致
  • 插件是否强制覆盖 From 地址，导致 DMARC 对齐失败
  • “强制 From”与其他表单、商城插件的设置是否冲突
  • 生产环境是否仍使用迁移测试时的临时账号
  • DNS 中是否还保留旧主机商自动生成的 SPF 或 DKIM
  • 定时任务、监控、工单系统是否使用另一套发信配置

不要把插件显示“邮件发送成功”当作投递成功。它通常只表示邮件已经交给 SMTP 服务器，后续仍可能被拒收、延迟或投进垃圾箱。

迁移完成后的验收清单

在切换 DNS 或结束迁移维护前，可以按下面的顺序验收：

  • 已确认所有网站、应用、监控和人工邮箱的实际发信渠道
  • 域名下只有一条 SPF 记录，且包含全部有效发信源
  • SPF 未超过 10 次 DNS 查询上限
  • 当前邮件可以稳定获得 dkim=pass
  • DKIM 的签名域与 From 域满足 DMARC 对齐要求
  • DMARC 已从 p=none 开始收集报告，并制定收紧计划
  • 自建邮件服务器的 PTR、A 记录和 HELO/EHLO 相互一致
  • Gmail、Outlook、Yahoo 等不同收件平台均完成测试
  • 已检查退信率、投诉率、黑名单和发送量变化
  • 旧服务器、旧 SMTP 和废弃密钥已停止使用并移除授权

邮件投递问题很少靠添加一条 DNS 记录就彻底解决。正确的处理顺序是先找出真实发信路径，再完成域名认证和反向解析，最后结合邮件头与信誉指标验证。这样即使以后再次迁移服务器，也能快速判断需要调整的是网站、邮件平台、DNS，还是发信信誉。

参考资料

资料核验日期：2026-09-28。

实操指南数据库运维

MySQL 磁盘空间突然不足？Binlog、临时表与大表增长排查指南

2026-9-28 15:28:30

实操指南知识库

RISC-V架构在服务器领域的应用潜力分析

2025-1-7 14:22:11