企业官网建设流程全解析

搜索“mautic 邮件发送”的人，绝大多数不是来学概念的。Mautic 已经装了，邮件模板也建好了，然后卡在了最尴尬的一步：点了发送测试，页面转圈，最后收件箱里什么都没有；或者测试信收到了，但一跑正式群发就几十封之后一动不动；再或者后台显示“已发送”，对方压根没收到。

这篇文章我就按自己实际部署和调优的经验，把这个链路上最容易让人抓瞎的环节一个个拆开讲。里面涉及的命令、配置、排查顺序，都是我实测过的，不是照着官方文档抄的。

1. Mautic 邮件发送链路里最容易踩的“五道关卡”

很多人把 Mautic 当成一个普通的“发信工具”，觉得跟 Outlook 一样写完点发送就行。这是最大的误解。

Mautic 是一款营销自动化平台，它的邮件模块本质上是一个队列系统 + 一个投递管道 + 一个回执处理系统。一封邮件从你点下“发送”到对方收件箱落地，中间要经过至少五个环节：

• 邮件进入队列：邮件状态变为pending，等待被发送进程拾取。
• 发送进程拉取：cron 或 CLI 命令去数据库里捞排队的邮件。
• 连接邮件通道：Mautic 通过 SMTP 或 API 连接到你的发信服务商。
• 外部投递：邮件服务商（比如你的企业邮局、Amazon SES、SendGrid 等）把信投递给收件方服务器。
• 回执处理：退信、打开、点击事件被 Mautic 收回来，更新联系人状态。

这五道关卡里，任何一道出问题，你看到的现象都是一样的：邮件没到。很多新手排查了半天，最后发现不是配置错了，而是队列根本没被消费。

1.1 队列机制：为什么后台显示“已发送”但对方没收到

Mautic 的批量发信不是实时执行。你在页面里点“发送”按钮，只是把邮件任务塞进了队列。真正干活的是命令行进程，或者你在界面里设置的那个“按分钟处理队列”的开关。

被误认为“故障”的现象通常是这样：

1. 后台邮件详情里显示邮件是pending状态，但过了很久还是pending。
2. 显示为sent，但收件人邮箱里确实没有。这种情况多半不是队列问题，而是投递通道被收件方拒收或者进了垃圾箱，稍后我会展开讲。

先说pending卡住的问题。最常见的原因是 cron 没有配，或者配了但 PHP 命令行执行的路径不对。你可以先用 CLI 手动跑一次，立刻就能看到真实报错：

cd /path/to/mautic php bin/console mautic:emails:send

如果这条命令没有任何输出且邮件开始发送，那说明 cron 配置有问题。如果命令直接抛异常，比如连接超时、认证失败，那问题在邮件通道配置上，不怪 cron。

1.2 发送锁和批次：为什么发几十封就停

Mautic 发一批邮件不是一次性把所有排队邮件全捞出来。它默认按max_batch_size分批，一批处理完再拉下一批。

有些人在后台看到邮件状态变成failed，而且数量不多，就没有细想。实际上问题经常出在“发送频率限制”和“批次大小”这两个参数上。

Mautic 的配置里有一组关键参数：

很多人把这个当成“压满就能发更多”，然后把max_batch_size调到 500，频率调成 1。结果是：SMTP 服务商发来 550 错误“too many connections”，Mautic 直接把这批全部标记为失败。

我踩过一次：当时给一个客户配了一台自建邮局，默认参数下每小时能发出去的量远达不到需求，我随手改了批次参数，结果一小时后服务商的封禁通知就来了。后来才明白，批次和频率必须跟邮件服务商的限制对齐，不是越大越好。

1.3 已进入“发送中”但卡住的隐藏锁

还有一个非常隐蔽的坑：Mautic 在发送过程中会写一个锁文件，防止多进程同时处理同一个邮件任务。如果你之前用 CLI 跑发送时 Ctrl+C 中断了进程，或者 crontab 里不小心配了两个重复的发送命令，锁文件可能一直残留。

现象是：邮件状态一会儿显示processing一会儿变成pending，但永远不会真正发出去。

遇到这种情况，先去看锁文件：

ls -la /var/www/mautic/var/cache/*/