换了邮件平台，销售仍用原来的公司地址发信，却发现报价邮件更容易进垃圾箱。此时先不要反复换标题或加大发送量。需要确认实际发信服务器是否改变、域名认证是否覆盖新服务，以及测试的邮件是否真的走了新链路。
先盘点哪些系统在发邮件
企业邮箱、网站表单、CRM自动跟进和订阅邮件可能由不同服务发送。列出每条链路的负责人、平台、可见发件地址、实际发送域和最近变更日期。网站通知正常，不能证明新订阅平台也配置正确；其中一条失败，也不代表全部邮箱都已失效。
迁移前保存原有DNS记录和服务配置，并确认哪些旧系统仍在运行。不要看到新平台给出一段SPF配置，就覆盖原来的授权。合并方式应按邮件服务商说明核对，避免修好了新平台，却让仍在用的发件服务失去授权。
看一封真实邮件的认证结果
从需要排查的系统发送一封受控测试邮件，在收件端查看原始邮件或完整标头。记录SPF、DKIM、DMARC结果，以及参与验证的域名。仅在DNS管理页面看到记录存在，不等于这封邮件已经通过验证。
- SPF：检查实际发信来源是否获得相关域的授权，不能只对照可见From地址。
- DKIM：检查是否有有效签名，签名域和选择器是否对应当前平台。
- DMARC：检查通过验证的SPF或DKIM身份是否与可见From域满足对齐要求，不能把任意一个“pass”当成全部通过。
针对发往个人Gmail账号的邮件，Google发件方指南分别列出普通发件方与大量发件方的要求，并解释认证、DNS、TLS及退订条件。适用要求要按当前发送方式核对，不把某个服务商面向个人邮箱的规则直接当成所有收件系统的统一配置。
认证通过后，仍要观察实际投递
通过认证不等于保证进入收件箱。发送节奏、收件人反馈、域名或共享IP信誉，以及订阅关系都可能影响结果。迁移后先对有合理接收预期的少量地址测试，核邮件内容、链接和退订功能，再按服务商建议逐步恢复发送，不用突发大量邮件来“测试稳定性”。
遇到退信，保存完整SMTP响应、时间、收件域和对应任务编号。暂时性延迟与永久性拒绝要分开；即便属于永久性拒绝，也要看具体原因，不能一律删掉收件地址。有些问题需要修复认证或发送配置。
光算的发信认证与邮件投递排查说明可以帮助中文业务团队理解SPF、DKIM和DMARC的分工。实际错误码和具体修复步骤应再对照当前邮件服务商及收件方文档。
给迁移留一个可判断的结论
每条发信链路记录测试时间、发件服务、认证结果、是否退信和收件端实际位置。不要只写“测试成功”：服务端已接受、邮件已送达与进入主收件箱是不同结果。Google也明确指出，第三方打开率不能直接证明送达或垃圾分类情况。
确认新平台工作正常并处理完存量任务后，再按迁移计划撤销不再使用的旧授权。保留必要的回退资料，但不要让无人管理的旧平台长期拥有发信权限。最终交接的是每条业务邮件链路，而不只是一张DNS截图。