症状：Compliance status dashboard 显示正常，测试邮件却没有出现在收件箱。
最快结论：Gmail Compliance status dashboard 邮件发布验收只能用来核对发件要求是否合规，不能证明某一封邮件已发送、被接收或进入收件箱。本周建议把域名合规检查和受控测试收件列为两项发布证据，分别记录检查对象、来源与结论。
独立开发者：核实自家发件域名对个人 Gmail 的合规状态。
QA 工程师：用受控地址确认测试邮件真实可读。
基础设施维护者与发布负责人：分别维护配置证据和应用功能验收记录。
发布验收的两条证据线
Google 将 Compliance status dashboard 定义为检查发往个人 Gmail 账户的邮件是否符合发件要求的工具，而不是追踪单封邮件的收件箱。它提供的是发件域名层面的合规信息；某个要求显示正常，不等于某次测试的邮件已被收件方接受，更不等于它出现在收件箱。(Google 对 Compliance status dashboard 的说明)
| 验收对象 | 能回答的问题 | 不能据此下的结论 | 适合留存的证据 |
|---|---|---|---|
| 发件域名合规状态 | 仪表板列出的发件要求目前显示什么状态 | 本次邮件已进入收件箱 | 域名、目标账户范围、仪表板状态与检查日期 |
| 单封测试邮件 | 测试地址是否收到邮件，主题和内容是否正确 | 域名已满足所有发件要求 | 测试用例、目标地址、邮件内容与收件结果 |
| 应用发送链路 | 应用是否生成邮件、提交发送请求并处理返回结果 | Gmail 已接受邮件或已将其放进收件箱 | 应用日志、发送服务返回信息及对应的收件记录 |
发布记录应把这几类证据分开。应用日志证明的是应用或发送服务记录了什么；受控收件证明的是测试地址实际观察到了什么。它们都不能单独替代域名合规状态。
独立开发者：先确认目标账户范围
查看状态前，先确定测试邮件的目标是个人 Gmail 账户，还是 Google Workspace 账户。Google 明确说明，发件指南及相关执行要求适用于发往个人 Gmail 账户的邮件，不适用于发往 Workspace 账户的邮件；但 Workspace 发件人向个人 Gmail 发信时仍须遵守相关要求。把两种目标混在一个验收结论里，会让结果看起来覆盖了实际并未检查的范围。(Google 对发件要求适用范围的说明)
| 测试目标 | Compliance status dashboard 的适用性 | 验收记录怎么写 |
|---|---|---|
| 个人 Gmail 账户 | 可用于核对发件要求相关状态；不证明单封邮件收件 | 写明目标是个人 Gmail，并单独附上收件证据 |
| Google Workspace 账户 | 不能把面向个人 Gmail 的状态当作该 Workspace 收件目标的合规结论 | 标明目标为 Workspace，另用受控收件流程验收 |
| 两类账户都要测试 | 需要拆成不同目标、分别收集证据 | 不把其中一个目标的结果泛化到另一类账户 |
建一条最小测试记录：发件域名、邮件类型、测试目标、测试用例编号。若事务邮件和营销邮件使用不同发件域名，也要分别记清楚，避免把一个域名的状态写成另一个域名的结论。
基础设施维护者：按适用范围核对发件要求
先在 Google 的发件指南核实当前适用要求，再读仪表板中的具体项目和状态说明。面向所有发件人的项目包括 SPF 与 DKIM 身份验证、DNS 记录、邮件格式、加密和用户报告的垃圾邮件率；DMARC、单键退订和遵守退订请求等项目则只适用于批量发件人。不要把某一类发件人的全部要求，未经核实地套到每个小规模测试场景。
Google 将批量发件人界定为在 24 小时内向 Gmail 账户发送约 5,000 封或更多邮件的发件人。达到适用条件时，应进一步核查相关要求，而不是只看一般发件人的状态项目。项目说明和适用边界可对照 Google 的发件要求与 Postmaster Tools 常见问题。
| 仪表板状态 | 可采取的动作 | 不应推断的内容 |
|---|---|---|
| Compliant | 按提示留存检查记录；继续执行单封邮件验收 | 所有邮件都能投递，或必进收件箱 |
| Needs work | 按该项目的说明核查发件系统和邮件本身；修复后复查 | 单封测试邮件必然因此被拒收 |
| No data found | 先核对数据是否足以评估；需要时用 Google Admin Toolbox 检查当前 DNS 状态 | 域名配置当前必定错误，或必定正确 |
仪表板数据不是实时数据。Google 说明，数据通常在 24 小时内更新，但也可能更久；部分变更需要等待，状态才会反映出来。低发信量时，仪表板也可能因隐私保护而缺少部分数据。可对照仪表板说明和Postmaster Tools 域名设置说明确认数据范围；若要检查当前 DNS 配置，可使用Google Admin Toolbox中的 Check MX。仪表板历史数据与当前 DNS 检查回答的问题不同，不能互相替代。
QA 工程师：怎样补上测试邮件真实收件证据？
要判断邮件是否真正到达测试端，必须操作受控收件流程。只在应用日志里看到“已提交”，或看到域名状态正常，都不等于 QA 已经读到邮件。把该次测试与目标地址、邮件内容和用例编号关联，才方便确认究竟验证了哪个产品行为。
可按这个顺序执行：
- 准备测试对象。 使用只用于自家产品或获授权环境的测试账号；记录发件域名和目标属于个人 Gmail 还是 Workspace。
- 触发单一用例。 例如注册验证、密码重置或通知邮件。一次聚焦一个场景，避免把多封邮件混成同一条验收证据。
- 保存发送侧记录。 记下应用生成的主题、关键正文、触发时间和发送服务返回信息。日志应能对应到该用例，但不能冒充收件证明。
- 检查受控收件端。 确认测试邮件是否可见、主题和正文是否符合预期，并记录实际观察到的结果；若未看到邮件，保留“未观察到”而不是推断其已进入垃圾箱。
- 关联双方证据。 将收件记录与测试用例、目标地址及应用日志关联。若地址会过期，先确认测试窗口够用；临时邮箱有效期说明可帮助判断地址是否适合这轮测试。
- 保留结论边界。 写明本次测试只证明该目标、该用例和该次收件观察，不把单次成功写成普遍送达保证。
受控收件可以用自有测试邮箱，也可以按测试时长选择临时邮箱或长期邮箱别名。若需要在不同注册流程中重复测试，可参考临时邮箱与邮箱别名的差异：是否要长期找回账号、等待后续通知或接收回复，都会改变地址选择。无论选哪种地址，都不能用一次测试推断所有收件方的结果。
发布负责人：分别签收域名与应用闭环
发布审批时，把域名合规检查和应用邮件功能列为两个独立证据项。前者回答发件域名在仪表板所列项目上的状态；后者回答这次产品邮件是否生成、是否在受控收件端真实可读。只勾选其中一项，发布记录就仍缺一条证据链。
| 评审项 | 最低记录内容 | 评审结论的边界 |
|---|---|---|
| 域名合规 | 发件域名、个人 Gmail 或 Workspace 范围、仪表板项目状态、检查日期 | 仅说明所列范围与检查时点的合规状态 |
| 应用闭环 | 用例编号、目标地址、应用发送记录、收件端结果 | 仅说明本次用例在该目标上的观察结果 |
| 发布决定 | 未通过项、责任人、复查条件、例外说明 | 不承诺所有用户、所有邮箱服务或后续邮件都能收到 |
若状态正常但测试邮箱没有邮件，先把问题拆开：核对目标账户范围、测试地址是否正确、应用是否生成并提交该邮件，再检查受控收件端实际观察到什么。不要因为仪表板显示正常就跳过应用链路核查，也不要仅凭一次未收到邮件就断言域名不合规。Google 的发件要求可能导致邮件被拒收或进入垃圾邮件，但单次收件观察不能独立确定具体原因。
团队交接：保留分工与复核触发条件
建议由基础设施维护者负责记录域名合规检查，由 QA 负责单封邮件的受控收件，由发布负责人检查两类证据是否覆盖本次发布范围。记录可以很短，但要写清谁检查了什么、证据来自哪里、结论适用于哪个目标。
遇到以下情况时，重新核对适用范围或补跑测试：
- 发件域名、认证配置或邮件类型发生变化；
- 测试目标从个人 Gmail 改为 Workspace，或反向切换；
- 仪表板指南或项目定义更新；
- 仪表板状态与本次收件观察不一致。
这种不一致不代表其中一项必然错误。仪表板使用的并非实时数据，且可能受主域名、子域名及低发信量等条件影响；受控收件则只反映那次测试在指定目标上的观察。把两条证据链分开追查，才能避免把合规状态误写成单封邮件的投递证明。
如果发布验收还缺单封邮件的实收证据，可以先用受控地址补齐“测试端是否实际收到并能读懂内容”这一项。对于只需临时注册、试用或收一次验证码的自家测试流程，Fwdsky 提供无需注册即可使用的临时收件箱；它适合作为一种受控测试方案，不保证所有邮件必达，也不适合银行、支付、政务或需要长期找回的账户。需要开始测试时，可从 Fwdsky 临时邮箱获取地址，再按上述步骤保存本次收件证据。