WordPress 网站换了托管商，企业邮箱不会因为网站文件和数据库复制过去就自动迁好。要先问邮箱实际由谁提供：独立的企业邮箱通常仍在原服务；若邮箱建在旧主机账号里，停掉旧主机可能连邮箱也停掉。DNS 是否要搬，则取决于只改网站解析，还是连域名的权威 DNS 一起更换。询盘通知又是第三件事：表单能提交，不代表新服务器还能发信，更不代表销售已经收到。 域名与邮箱实际归属确定后，再核WordPress 表单通知的接收链路，避免站点能打开却漏掉询盘。
先画清边界：网站、邮箱、DNS 和通知不是一个包裹
网站迁移通常涉及 WordPress 文件、媒体、插件、数据库及运行配置，WordPress 官方迁移说明也先要求备份文件和数据库；它没有替企业邮箱复制邮件、创建账号或迁移历史信件。采购时请旧服务商列出邮箱供应商、管理入口、邮箱与别名数量、历史邮件保管位置、续费人与旧主机停用后的影响。只给一张网站备份截图，不能回答这些问题。
以“官网搬走，邮箱仍由原来的独立邮件平台提供”为例，采购任务是保持收发路径并验证，不是再买一次邮箱迁移。反过来，如果邮箱就在旧主机面板内，“网站迁移免费”也不能推定历史邮件、联系人、别名和客户端设置已经纳入。需单独确认邮箱迁移的实施者、数据范围、费用和切换条件；未确认前先别停旧账号。
光算目前的WordPress 托管与优化服务页写有免费网站迁移，涵盖现站检查、备份、预迁移、测试和上线切换，并要求切换前核对域名解析、SSL、邮件及表单；迁移窗口与数据同步方式另行确认。这里的“核对邮件”不能擅自解释成“包含企业邮箱账号和历史邮件搬迁”。若买的是新建外贸 B2B 网站，页面另写“协助配置企业邮箱”，两种服务范围也不能混用。
只改网站 A 记录，还是更换 NS？这一问决定 DNS 工作量
先请域名管理员确认当前权威 DNS 在哪。只调整网站用的 A／AAAA 或 www CNAME，通常不必把邮件 MX 指向新主机；但要检查 mail.example.com 等邮件主机名是否仍指向旧服务器。如果改的是注册商处的 NS，等于换了管理整区记录的地方，网站记录与邮件记录都要在新 DNS 区逐项对照后再切。Cloudflare 的完整接入说明要求先审记录、后改 NS；其快速扫描限制说明特别提醒，自定义主机名或 DKIM 选择器可能没被自动发现。
不要只问“MX 有没有复制”。要把记录名、类型、目标值、优先级（MX）、当前与目标 DNS 区、修改人一并保存。MX 决定来信送到哪个邮件系统；若 MX 指向自有的 mail 子域，还要检查该主机名的地址记录。企业邮箱供应商给出的域名验证、自动发现等记录，也应按实际在用功能核对，而不是拿别家的一套示例值直接粘贴。Cloudflare 的邮件记录说明可用于辨认收信和域名验证记录的分工。
SPF、DKIM、DMARC 查的是发信身份，不能拿 MX 代替
网站表单可能沿用旧服务器发信，也可能调用独立 SMTP 或邮件 API；换主机后先认清实际发信路径。SPF 是对合法发信来源的声明，同一域名或子域名不要新增第二条 SPF 策略，Microsoft 的 SPF 配置说明指出重复策略会导致验证错误。需要增加新发送方时，应由邮件管理员在现有策略与服务商要求之间核对，不能覆盖正在使用的其他业务发信来源。
DKIM 要看实际发送系统使用的签名域与选择器，DNS 区中对应记录是否存在；DMARC 还要看显示给收件人的 From 域与 SPF 或 DKIM 验证的域是否对齐。即便某项 SPF 或 DKIM 显示通过，域名不对齐仍可能使 DMARC 失败。Microsoft 的 DMARC 诊断说明给出了检查邮件头中 smtp.mailfrom、header.d 和 header.from 的办法。不要为了通过上线测试就擅自把现有 DMARC 策略改成不执行；先找出哪个合法发信系统未正确配置。
用同一个测试编号，分别拿到“表单已收、通知已达、邮箱可回”
正式切换前后各做一轮，不要只在预迁移站点点一次提交。选一个不会混入真实客户资料的测试编号，分别由外部测试邮箱发信到企业销售邮箱、由网站产品页提交测试询盘，再从销售邮箱回复外部测试邮箱。网站、邮件与销售三方用同一个编号对账，记录提交时刻、页面与字段、后台是否保存、发送服务日志是否接受、收件箱或垃圾箱是否到达，以及回复是否正常。若项目有自动回复、附件或订单通知，按约定另测；“发送接受”与“收件人看到”分开写。
表单显示成功却没有后台记录，先查网站接收和保存；有记录而销售没收到，追发信连接、收件人配置、过滤与退信；信到了却回复错人，再查 From／Reply-To。WordPress 的 wp_mail() 说明明确说返回成功不等于用户收到了邮件。具体表单插件的收件地址、发件身份、回复地址与附件设置，要在现站和新站分别实查，不能照搬某一插件的菜单路径。验收由实际接收询盘的销售共同完成，不能由开发人员只看发送日志代签。
签约前让双方填写一张“四栏放行单”
这不是光算既定合同模板，而是供采购方逐项问清的空白工作单。每栏都填“现状—要改什么—谁操作／谁批准—凭什么放行”；留空的项目不能写已包含或已通过。
- 网站：原站与新站、文件及数据库范围＿＿；是否保留原域名和 URL＿＿；预迁移访问、最终数据同步及旧站保留由谁做＿＿；放行证据为正式域名的代表页面与表单记录＿＿。
- 邮箱：供应商和账号归属＿＿；独立保留／随旧主机关停／确需另迁＿＿；历史邮件、别名和客户端是否另交付＿＿；谁能确认外部来信、发信及回复均可用＿＿。
- DNS：只改网站解析还是更换 NS＿＿；旧新记录清单由谁导出、谁逐条复核＿＿；MX、SPF、DKIM、DMARC 及关联 mail 主机名是否核对＿＿；谁有权限改解析、谁批准切换＿＿。
- 通知：表单接收位置、销售收件人、网站实际发送渠道＿＿；测试编号、后台记录、发送日志、实际到件与回复结果＿＿；失败时由网站方、邮件方还是 DNS 管理员先接单＿＿。
切换指令应由被授权的负责人在上述证据齐备后发出；如果某一栏没有访问权限，写明谁补资料、何时补测，别把“技术人员说应该没问题”当成验收。报价也按栏标清套餐已含、另议或企业自管。尤其是邮箱搬迁，不因网站免费迁移而自动变成免费或已安排。
回滚要能保住新产生的询盘，不只是把 DNS 改回去
实施前约定暂停或回退的触发条件，例如销售无法接收外部邮件、表单只显示成功却无记录、关键页面不可用；由谁判断、通知谁、旧网站和旧邮箱何时可以关停，都写在实施单。保留切换前的网站备份及旧 DNS 记录，核对新站切换后新增的询盘与订单；若只恢复旧数据库，新增记录可能留在新站。DNS 回改也不会自动复制新邮箱里收到的邮件，所以网站回退与邮箱回退必须分别有数据处理和复测责任人。
如果还伴随换域名或改 URL，另按网站改版迁移验收清单处理旧新网址，不把 SEO 映射混进这次邮箱问单。准备换 WordPress 托管商时，可以先带现站网址、邮箱实际供应商、DNS 管理权限和表单接收路径，向光算 WordPress 托管服务确认网站迁移、邮件核对与额外邮箱迁移各由谁负责，再决定切换窗口。 切换前先明确WordPress 邮件发送依赖的 DNS 记录由谁维护，再测真实询盘。