在自建服务体系中，电子邮件服务器是最基础、也最容易踩坑的一类服务。
要求往往非常苛刻：
- 必须 完全自托管
- 必须 免费、功能完整
- 必须 支持 Docker
- 同时还要面对现实问题：
资源占用、稳定性、送达率、维护成本
经过方案调研与实际部署，最终选择了 Mailcow（Dockerized），并已经稳定运行超过半年。
这篇文章对这段使用经历做一次阶段性技术复盘。
可选方案简要回顾
在选择 Mailcow 之前，常见的自建邮件方案主要包括：
- Docker-Mailserver（极简、无 Web UI）
- Poste.io（单容器、一体化）
- Mailu（模块化、资源中等）
- Mailcow（组件最全、资源需求最高）
如果仅从功能完整度出发，这些方案的差异非常明显。
内存需求排序（从低到高）
从实际运行经验和社区共识来看，内存需求大致如下：
- Docker-Mailserver
- 0.5–1 GB 可运行
- 无 Web 管理界面
- 适合资源极度受限场景
- Poste.io
- ~0.7 GB（关闭杀毒可更低）
- 单容器、带 Web UI
- 功能集中但可定制性有限
- Mailu
- ~2 GB 起
- 模块化设计
- 功能与资源消耗较平衡
- Mailcow
- 官方建议 ≥6 GB（含反垃圾、杀毒、协作组件）
- 功能最全
- 资源占用最高
结论很直接：Mailcow 不是最轻量，但是功能最完整的方案。
为什么最终选择 Mailcow
Mailcow 的定位非常明确：
完整邮件系统，而不仅仅是“能收发邮件”
其优势主要体现在：
- 完整 SMTP / IMAP / POP3 协议栈
- Web 管理后台
- 集成 Webmail（SOGo）
- Rspamd 反垃圾体系
- ClamAV 反病毒（可选）
- DKIM / SPF / DMARC 全支持
- 自动 TLS（Let’s Encrypt）
- 多域名、多用户、配额、别名
- 日志、监控、统计齐全
本质上，它更接近 “企业邮件系统的自建实现”。
半年稳定运行意味着什么
连续运行半年，且未出现结构性问题，本身已经说明：
- 架构设计是成熟的
- Docker 编排是稳定的
- 日常维护频率是可控的
- 升级、重启不会引发连锁故障
这也是 Mailcow 相比轻量方案的重要优势：
不是实验性质，而是长期可运行的基础设施。
半年节点的关键检查项
在运行半年后，有必要对以下几个关键点进行一次确认，而不是盲目“继续堆功能”。
1. DKIM / SPF / DMARC 状态
这直接决定邮件是否进垃圾箱。
至少需要确认：
- DKIM key 是否一致
- SPF 是否覆盖真实发信 IP
- DMARC 是否明确策略（none / quarantine / reject）
2. Rspamd 是否真正参与了“学习”
如果半年内：
- 从未标记 spam / ham
- 从未调整打分或白名单
那么反垃圾系统只是“存在”，而不是“被使用”。
3. ClamAV 是否仍然值得开启
现实结论往往是：
- 小规模、自用邮箱
- 收到的附件来源可控
在这种情况下，ClamAV 的收益往往低于其内存成本。
关闭后可显著降低整体内存占用，而不影响核心邮件功能。
4. 备份是否“可恢复”
关键问题只有一个：
是否有信心在完全清空容器和卷之后，完整恢复邮件系统？
如果答案是否定的，那么当前备份策略并不合格。
5. IP / rDNS / 信誉状态
长期运行必须关注：
- rDNS 是否仍正确指向域名
- IP 是否进入常见黑名单
这是所有自建邮件服务器的生命线。
6. 更新策略是否克制
Mailcow 并不适合：
- 每天追最新版本
- 也不适合永远不更新
一个理性的节奏是：
2–3 个月一次，有问题可回滚。
阶段性结论
Mailcow 是可以运行多年的方案，而不是临时测试工具。
在进入稳定期后，更重要的不是继续加功能，而是：
- 减少不必要的组件
- 降低维护频率
- 把它当作“基础设施”，而不是“项目”
当一个系统开始“被忽略却依然正常运行”，
往往才说明它真正成熟了。