后台已经出现新订单，客户却一直收不到确认邮件。先不要立刻重发，也不要只测试 SMTP 连接。Magento 的订单邮件会经过“是否允许发送、是否异步、Cron 是否处理、传输是否成功、邮件服务是否投递”多个阶段，任何一处断开都会得到相同的用户反馈。

先看订单是否被标记为需要发送

在只读数据库连接中检查订单的邮件状态：

SELECT entity_id, increment_id, customer_email,
       send_email, email_sent, created_at
FROM sales_order
WHERE increment_id = '000000123';

send_email 表示业务流程是否请求发送，email_sent 表示 Magento 是否认为发送已完成。字段值不能证明客户邮箱最终收到邮件，但能帮助确定问题发生在发送前还是传输后。不要直接把 email_sent 改成 0 作为重试方式，重复发送会影响客户体验，也可能触发营销或 ERP 流程。

异步发送依赖 sales Cron 组

启用 Asynchronous sending 后，订单、发票、发货和退款邮件不会都在 Web 请求内立即发送。检查 Cron 安装与计划：

bin/magento cron:run --group default
bin/magento cron:run --group sales
SELECT job_code, status, scheduled_at, executed_at, finished_at, messages
FROM cron_schedule
WHERE job_code LIKE '%email%'
ORDER BY schedule_id DESC
LIMIT 30;

不同版本和模块的 job code 可能不同，因此还要按执行时间和 sales 组确认。若计划根本没有生成，检查系统 crontab；计划存在但长期 pending，检查 cron 进程锁和消费者资源；状态 error 则读取 messages 与 Magento 日志。

邮件传输成功不等于投递成功

Magento 把消息交给 sendmail、Postfix 或 SMTP 服务后，应用层可能已经标记成功。继续查看邮件服务器日志或 SMTP 服务的 message ID、退信和抑制列表。发件域 SPF、DKIM、DMARC 错误，收件地址被 suppression，或服务商限流，都会导致 Magento 日志看似正常而客户收不到。

第三方 SMTP 模块可能记录完整邮件内容和凭据。生产日志应隐藏认证信息和客户隐私，只保留必要的请求 ID、收件域、响应码与 message ID。

只有某类邮件失败时查模板与事件

订单邮件正常、发票邮件失败，通常不是 SMTP 全局故障。检查对应 Sales Emails 配置、商店作用域、模板是否存在，以及自定义模板变量是否抛出异常。多商店站点要确认订单所属 Store View 的发件人和模板，而不是只看 Default Config。

支付扩展也可能故意延迟订单邮件，直到支付回调把订单更新为允许状态。对照支付 webhook 时间与 send_email 变化，避免在未付款状态提前发送错误的确认内容。

恢复后用受控测试邮箱完成一笔新订单，记录订单创建、Cron 执行、SMTP 接受和最终收件四个时间点。再测试发票与发货邮件，确认不是仅靠后台“重发邮件”绕过了异步链路。