先发送一封带唯一标记的受控测试邮件，再分别检查原收件端、转发目标和邮件内容；只有在主邮箱实际找到并能读懂对应邮件，才算完成主邮箱收件验证。这个方法适用于你自己的产品或获授权的测试环境，发送成功和转发规则已启用都不等于目标端已经实收。
负责自家邮件转发或通知链路的开发者，可以据此区分发送、转发和实收证据。
QA 工程师可以用不同转发条件设计可复现的验收用例。
独立开发者可以核对临时收件地址转发后，主邮箱里的内容是否完整可读。
先把验收证据分开
邮件链路上常被混为一谈的，是“发出去了”“原收件地址收到了”“转发程序处理了”和“目标邮箱收到了”。这些状态对应不同观察点：发送端的成功响应说明 SMTP 交互到达某个阶段，不直接证明最终投递；原地址收件也只证明邮件到达原收件端；规则页面显示启用，只能证明配置状态。
开始测试前，为邮件设置容易识别的主题或正文标记，例如 relay-check-qa-20261029-A。同一轮只测试自家产品或获授权环境，不要拿第三方平台批量创建账号，也不要把真实客户资料、个人验证码或支付信息放进测试邮件。
| 观察点 | 可以证明什么 | 不能单独证明什么 |
|---|---|---|
| 发信端响应、任务日志 | 应用尝试发送，或发送端记录了处理结果 | 原收件端或主邮箱已实际收件 |
| 原收件箱 | 测试邮件已到达原收件端 | 转发规则已命中、目标端已收件 |
| 转发处理记录 | 产品记录了转发尝试及其状态 | 目标邮箱已显示邮件且内容可读 |
| 主邮箱中的邮件 | 目标端实际收到了可检查的邮件 | 所有目标地址、条件或后续邮件都必定成功 |
因此，记录时要写清每个证据来自哪里。验收表只写“成功”很难复现；写成“发信日志有记录、原收件箱找到标记、转发记录显示已处理、主邮箱搜索到对应邮件”更容易定位中间断点。
全量转发场景
全量转发的重点，是确认新邮件是否从原收件端继续到达指定主邮箱。测试时先确认目标地址没有拼写错误、转发规则已保存，然后从获授权的测试发件端触发一封带唯一主题的邮件。
分别打开原收件端和主邮箱，搜索同一个标记。原端有、主邮箱没有时，不要马上重发多次：先查转发记录和失败原因，再检查主邮箱的垃圾邮件、隔离区或过滤规则。主邮箱找到邮件后，再核对发件人显示、主题、正文、关键链接和附件；规则启用状态不能替代这个核对步骤。
| 检查对象 | 验收动作 | 失败时先看 |
|---|---|---|
| 原收件端 | 搜索唯一主题，打开邮件 | 发信日志、原地址、投递状态 |
| 转发处理 | 按主题或关联标识查处理记录 | 规则是否命中、目标地址、失败原因 |
| 主邮箱 | 搜索标记，打开邮件并检查内容 | 垃圾邮件、隔离区、收件规则 |
| 邮件内容 | 对照预期核对正文、链接与附件 | MIME 内容、编码、转发处理是否改写 |
这类邮件转发测试适合验证单封新邮件的完整链路。如果还要验收注册、密码重置等多封邮件组成的流程，可以参考注册测试的收件与验证路径，但要把每个步骤对应的邮件分别关联起来，不要仅凭最后一封邮件推断此前步骤都成功。
条件筛选场景
筛选转发需要一对对照邮件：一封满足条件，一封不满足条件。条件可以是自家产品所支持的发件地址、主题特征或其他规则；具体用什么字段、比较方式和大小写处理，应以正在验收的产品实现为准，不能假设不同系统行为一致。
每次尽量只改变一个与筛选有关的属性。例如，主题标记保持一致，仅调整测试条件指定的发件人字段。这样若结果不符，才更容易区分“规则没命中”和“邮件命中后下游投递失败”。分别检查原收件端、规则处理记录和目标邮箱：匹配邮件应按产品设计转发，不匹配邮件则应按设计不转发或留在原端。
注意：没有出现在主邮箱，不一定表示筛选规则正常拦截。先确认原收件端确实收到不匹配邮件，再查规则记录，避免把上游未投递误判为条件筛选成功。
筛选验收还要关注边界输入：相似但不完全相同的主题、发件人显示名与地址的差别、缺少筛选字段的邮件。边界测试应针对自家产品的规则定义来写，不要将某个目标邮箱或转发服务的过滤表现当作通用标准。
漏转、重复与内容差异
出现异常时，按可观察症状切开排查，而不是只重置规则。
- 原收件端没有邮件：先回到发送日志，核对应用是否真正触发发送、目标地址是否正确，以及发送环节是否记录失败或延迟。此时还没有证据表明问题在转发端。
- 原端有、目标端没有：检查该邮件是否符合转发条件，再查处理记录、目标地址和失败状态。接着查看主邮箱的垃圾邮件、隔离区或自定义规则。
- 目标端收到多封：比较每封邮件的主题、正文标记、Message-ID 和到达路径线索。确认是同一封邮件被重复处理，还是测试脚本实际触发了多次发送。
- 邮件到达但内容不同：先比较主题、正文、关键链接和附件是否符合自家产品预期，再判断差异是否来自转发处理或目标邮箱的展示方式。
原始邮件和转发邮件不一定逐字段相同。转发过程可能增加追踪字段、改变信封路由信息，或对消息内容和部分头字段作处理；因此，不应只因 To、Received 或签名相关字段变化就认定转发故障。若要理解临时收件箱、邮件沙箱与真实投递路径的差异，可继续看临时邮箱与邮件沙箱的适用边界。
邮件头与内容的核验范围
测试邮件头时，先用主题标记或 Message-ID 关联原邮件与转发副本。RFC 5322 将 From、To、Message-ID 等定义为消息格式中的常见头字段；其中 Message-ID 是用于标识特定邮件版本的标识符。转发时新增追踪字段，并不必然意味着邮件身份改变。具体字段定义可查阅 RFC 5322 的邮件格式标准。
Received 是 SMTP 传输路径中的追踪字段，通常按服务器追加的顺序从最新记录向更早记录查看。它适合帮助识别邮件经过哪些处理节点，但记录内容和完整程度受各处理系统影响；它不是目标收件箱的截图，也不能证明用户可见邮件已经实际送达。相关含义见 RFC 5321 的 SMTP 规范。
正文不完整时，检查 MIME 结构而非只对比纯文本预览。邮件可能含有纯文本和 HTML 等不同内容部分，Content-Type、Content-Transfer-Encoding 等字段会影响内容如何表示与解码；可参考 RFC 2045 对邮件正文格式和传输编码的定义与 RFC 2046 对多部分内容结构的说明。若邮件含附件，实际打开附件并核对文件是否完整，比只看附件名称更可靠。
转发可能对邮件内容或头字段作修改，因此原有 DKIM 签名的验证结果也可能受影响；不能把签名状态单独当作转发成功与否的判据。RFC 6376 对转发和消息修改的讨论可帮助理解这类差异。ARC 则用于记录处理环节中的认证评估信息，不等于目标邮箱已实收，也不代表邮件内容安全；边界可参阅 RFC 8617 的 ARC 说明。
验收后的可勾选清单
每轮测试结束前，按这份清单留下可复核结果：
- [ ] 在自家产品或获授权环境中触发邮件，并在主题或正文加入唯一标记。
- [ ] 记录发送端结果，确认对应测试事件确实发生。
- [ ] 打开原收件端，确认标记邮件实际存在。
- [ ] 按全量或筛选场景检查转发规则与处理记录，不用“规则已启用”替代收件证据。
- [ ] 打开目标主邮箱，确认同一标记邮件实际出现，而非只看处理状态。
- [ ] 检查主题、正文、链接和附件；内容要求不同的场景分别记录。
- [ ] 对照原件与转发件的 Message-ID、Received 和 MIME 内容，标出差异，不把单个头字段变化直接记为失败。
- [ ] 保存原收件端与目标端的可复核记录；测试完成后清理临时账号和含测试数据的邮件。
常见验收判断
主邮箱搜不到邮件时，怎样确认转发是否真的发生？
先确认原收件端有对应标记，再查转发处理记录。若记录显示没有命中，回查筛选条件；若显示处理失败，核对目标地址和失败线索。最后检查主邮箱的垃圾邮件或隔离区。只有在目标邮箱找到邮件，才能确认它实际到达该邮箱。
邮件到了但内容不完整，先查哪里？
先用标记或 Message-ID 确认比较的是同一封邮件，再核对 HTML 与纯文本内容、附件和链接。结合 MIME 头部判断是否存在多部分内容或编码问题；同时对照原件和转发件，确认差异是否符合自家产品的转发设计。
如何验收筛选只转发符合条件的邮件？
准备匹配与不匹配的受控邮件，分别检查原收件端、规则处理记录和目标邮箱。尽量每轮只改变一个筛选属性，避免把规则未命中、上游未送达和目标端未收件混为一谈。测试结果只适用于被测产品的规则定义。
原地址收到、主邮箱没有，该怎么定位？
以原端收件为起点，核对转发规则是否匹配、产品是否有处理记录、目标地址是否正确，再查主邮箱的过滤区。若处理记录缺失或失败，从产品日志定位转发环节；邮件头中的 Received 只能提供路径线索，不是目标端实收证明。
临时收件与转发的适用边界
HideRelay 当前页面区分临时收件箱和转发地址：临时收件箱无需注册即可收信，地址到期会销毁；页面也说明长期转发使用固定别名，需登录后创建，并把来信转到已验证的真实邮箱。页面显示转发记录的保留期限为 30 天；这属于站点当前公开说明，不代表其他系统的记录保留方式，也不构成所有邮件必达承诺。地址有效期会显示倒计时，本文不把演示倒计时推断为固定期限。
这项能力不能替代前文的验收证据：临时收件箱用于检查邮件是否到达收件地址；若要验证转发到主邮箱，需使用适用的转发地址并以目标邮箱中的实际邮件为准。需要了解收件方式时，可查看HideRelay 的测试收件与转发说明；临时地址不适合银行、支付、政务等需要长期找回的重要账户，也不适合必须从该地址回复或长期接收通知的场景。
如果本次任务只是临时注册自家测试账号、验证一封通知或观察收件内容，HideRelay 的免注册临时收件可以作为一种测试方案；需要长期转发时，则应先确认固定地址与目标邮箱已按页面流程设置，再自行做端到端验收。两者都不应被当作必达保证，更不能取代对关键账户的长期邮箱管理。