这是给网站交付需求使用的合成教学例，不是客户成果、真实账号测试或认证。
邮件链路的哪一段真正有证据
网站可以成功接收询盘，但通知邮件稍后失败；邮件到达收件服务器，也不代表进了收件箱或被阅读。验收新表单流程时，要索取逐封邮件的证据链，不只看HTTP成功或“已发送”标签。
| 邮件 | 所填事件 | 有限报告 |
|---|---|---|
| M-DEMO-1 | sent、delivered及一条原样重复 | 收件服务器已接收；是否阅读未知 |
| M-DEMO-2 | sent、bounced | 退信 |
| M-DEMO-3 | 只有sent | 待确认 |
运行填好的例子
下载有限规则Node检查器和已填写输入。使用Node 24或更新版本，不需要账号或API，也不联网。
node checks.mjs enquiry-email-status-ledger enquiry-email-status-ledger.json输入是三个邮件编号、六行事件，其中一行完全重复。检查器输出duplicateEventRows 1，并保留三种不同状态。同事件编号被用于不同记录会报冲突；同一封同时出现delivered和bounced时返回REVIEW_CONFLICT，不凭数组顺序猜最终结果。
把测试变成网站交付要求
约定成功接收的询盘如何生成编号，以及通知邮件如何关联这个编号。再要求脱敏的服务商事件、永久失败处理队列及缺少事件时的负责人。重试前先约定去重，不应因重发通知而多建一条询盘或客户记录。
正式授权测试应分别证明表单存储、服务商接收与投递证据。人工确认及有效询盘要有自己的记录，投递事件不能证明成交、回复或实际阅读者身份。
演示不发邮件、不读取邮箱或服务商账号。字段是简化教学适配，不是完整Resend回调，也不是按时序运作的生产状态引擎。真实实现仍要处理验签、迟到事件、冲突与安全留存。
官方依据与边界
Resend事件类型：email.sent表示开始尝试发送；email.delivered表示到达收件邮件服务器，不表示人工阅读。
来源于2026年10月15日核验。输入与验收规则为原创教学设计；正式实施前还要核对当前平台版本及实际交付合同。