先看结论
先查网站有没有保存这条测试需求，再查邮件任务是否生成、发送服务是否接受、收件系统如何处理。SMTP accepted只证明传输某一环节接受，不能证明进入收件箱或被销售阅读。不要在证据不足时反复改DNS或把所有邮件改发私人邮箱。
四个状态要留下独立证据
先对照当前状态；窄屏可左右滑动查看完整表格。
| 环节 | 找什么记录 | 未通过先查 |
|---|---|---|
| 业务保存 | 编号、保存时间与测试标记 | 表单校验、接口、数据库错误 |
| 任务生成 | 事件、收件配置、队列状态 | 通知触发、配置与任务运行 |
| 发送接受 | 服务回执、消息ID与错误 | 认证、发件域、服务限制 |
| 收件与处理 | 收件箱/隔离、管理员日志、负责人 | 垃圾分类、规则、转发或无人跟进 |
用一封可识别的内部测试开始
在获准的测试里使用唯一标记、真实可控的测试邮箱与明确发送时间。不要批量给真实客户发试验通知。若页面显示失败，先核网站记录；若已经保存，避免重复提交制造一堆看似新客户的记录。
保存业务事件与邮件通知应能独立看状态。邮件失败时仍有需求编号和后台记录，运营人员才有机会补救；具体实现需要按当前系统验证，不能只凭文案宣布可靠。
检查域名认证与地址用法
Google的发件人指南解释了发件认证等要求，实际适用条件与发送方式需要当前核对。表单常见做法是用已授权的本站发件地址，买家地址作为合理配置的Reply-To，而非冒用买家域发信。
不要看到SPF、DKIM或DMARC名称就随意覆盖生产DNS。先记录当前服务、所有合法发件来源与现有记录，由邮件管理员核对变更。认证通过也不保证每封都进收件箱。
恢复后还要有人监控失败
给通知失败设置可见待办，明确谁处理、如何重试和何时改用备用渠道。重试必须避免对同一事件重复通知或误把测试计作真实线索。保留有限且受控的日志，别把邮件正文与客户图纸公开输出。
把建议变成操作
按步骤做，并留下能核对的证据
- 01
核对保存
用唯一标记找表单记录，不先改邮件配置。
留下的证据记下编号与业务保存时间。
- 02
核对发送
追踪通知任务与消息ID。
留下的证据区分未发送、接受、拒绝和待重试。
- 03
核对收件
由收件管理员查隔离、转发和相关日志。
留下的证据记录实际收件结果，不用接受回执替代。
- 04
复测与补救
修复后再次测试，并安排失败记录处理。
留下的证据已恢复结果、待办与责任人可对账。
可填写 / 可复制
把这份工作单带进项目
填写与勾选仅留在当前页面，不上传、不发送给统计工具，刷新后清空。请下载或打印自行保存。
我的验收清单
完成相应操作、拿到证据后再勾选；勾选不代表网站或Google已经替你验证。
这几个错误会让工作白做
accepted就写已送达
必须继续核对收件端。
同时改DNS与多个服务
会扩大影响且难以确认原因，先依据证据限定变更。
邮件没收到就丢弃需求
后台保存与人工待办应支持补救。
开始执行前，常见的问题
是不是换邮箱就能解决？
可能绕过某一问题，也可能掩盖真正原因。先确认失败环节及数据流向，再评估变更。
每封都需要人工查吗？
日常可以用失败待办和监测；交付验收及异常排查仍应追踪具体测试记录。
资料与适用边界
以下一手资料用于核对文中涉及的技术规则。项目拆解、比较表、工作模板与验收流程为LJWE编辑建议，不是官方强制流程，也不是已完成项目的实测记录。采用前请结合你的产品、工具版本与权限复核。
- Google：邮件发件人指南 ↗资料查阅：2026-10-21
本文没有引用客户成绩、市场均价或保证获客结果。涉及账号权属、商业授权、客户数据与保密义务时，应依据实际合同、平台条件和适用要求确认。