Mailcow：开源容器化邮件服务器实战，从DNS到投递的全链路避坑

简介Mailcow是一个基于Docker容器化技术构建的开源邮件服务器解决方案主要面向需要自建高效、安全邮件系统的运维人员与中小企业IT管理员。它整合了SMTP、IMAP、POP3、Webmail等服务并内置反垃圾、反病毒、DKIM、DMARC、SPF等安全功能有效解决传统邮件服务器部署复杂、维护困难的问题。这套资源包为Mailcow项目的完整文件共2000个文件以1515个PHP核心代码文件为主辅以Markdown文档、JSON配置文件、Shell脚本、XML配置、Dockerfile等这些文件分别承担了邮件处理逻辑、服务编排、参数自定义及自动化运维等角色可帮助读者深入理解整体架构与组件协作。压缩包大小约10.98MB目录结构清晰特别适合学习Docker Compose编排、多服务联动、邮件安全策略落地等场景。已有200人学习下载对希望快速掌握自建邮件服务器技术的读者具有实用参考价值。1. 自建邮箱到底图什么Mailcow 想解决的那几件事公司邮箱挂在第三方平台上管理员后台看不到邮件流转日志附件归档全部依赖对方良心团队邮件数据说不上被谁碰过——这种状态下想换一套能自主控制、功能又不缩水的开源邮件服务器Mailcow 是绕不开的名字。它不是某个单一软件而是一整套基于 Docker 编排的开源邮件服务器解决方案把 Postfix、Dovecot、SoGo、Rspamd、ClamAV 这些组件拼成一个开箱即用的全家桶覆盖收发信、Webmail、反垃圾、杀毒、证书续签全部环节。适合小团队自建、个人域名邮箱、或者想摆脱第三方平台束缚的企业 IT 负责人。硬件要求不高配置门槛主要体现在 DNS 和网络端口上这也是绝大多数人卡住的地方。2. 拆开 Mailcow 看看Postfix、Dovecot、Rspamd 与容器化的取舍2.1 从信件进门到出门一条完整的投递链路要理解 Mailcow 为什么好用得先看一封邮件在它内部是怎么流转的。外部发来的信先落在 Postfix 上Postfix 是邮件传输代理负责跟外部邮件系统说 SMTP 协议的话信收下来之后会依次经过 Rspamd 做反垃圾评分、ClamAV 查病毒这两关过了才交给 Dovecot 的 LDA 投递进程写进用户邮箱目录。发信的方向反过来客户端通过 587 端口提交邮件给 PostfixPostfix 对邮件做 DKIM 签名然后查询对方域名的 MX 记录把信投给对方的邮件服务器。这套链路里每个容器各管一段下表把组件职责列清楚。容器/组件职责对外端口PostfixSMTP 收发信、DKIM 签名25 / 587DovecotIMAP/POP3 存取、用户认证、本地投递143 / 993 / 110 / 995SoGoWebmail、通讯录、日历、会议邀请由前端入口转发Rspamd反垃圾评分、SPF/DKIM 校验内部端口ClamAV病毒扫描内部端口MySQL/MariaDB域名、邮箱账号、别名等元数据内部端口Redis会话缓存、Rspamd 统计、SoGo 状态内部端口Acme自动申请与续期 TLS 证书内部端口组件分离的价值在于改动面是可控的调反垃圾策略时你碰 Rspamd 就行没必要动 MTAWebmail 界面换皮肤也不会影响邮件投递主链路。如果你之前折腾过裸装邮件服务器应该感受过那种牵一发动全身的疼——改个 amavis 配置把整个服务搞挂的事我干过不止一次Mailcow 这种容器化的拼装方式至少让每次改动的爆炸半径变小了。2.2 为什么不是直接在服务器装一套邮件软件裸装一个邮件系统难点不在装包而在依赖冲突和升级包袱。Rspamd 和 ClamAV 对 libc 和编译器版本敏感CentOS 7 上编译 ClamAV 时踩了一下午的坑换了台 Debian 又遇到 Redis 版本不对导致 SoGo 会话写入失败。用 Docker Compose 编排之后这些依赖问题都被镜像隔离掉了你维护的是 compose 文件和几个数据卷而不是一台越滚越大的实体服务器。Mailcow 的配置体系分两层一层是根目录的mailcow.conf它保存域名、时区、数据库密码、证书策略这类顶层参数另一层是docker-compose.yml由配置脚本生成编排各容器。日常运维时不要去手工改docker-compose.yml里的容器参数临时想加内存限制或改日志轮转正确做法是写一个docker-compose.override.ymlcompose 启动时会自动合并加载。这个习惯养成以后升级 Mailcow 版本时你的自定义项不会因为重新生成配置而丢失。3. 从空白服务器到第一封邮件部署步骤与 mailcow.conf 关键参数3.1 前置条件域名、DNS 与机器资源部署前先把 DNS 捋清楚这是整个项目里最容易翻车的一步。你需要一个域名最好把子域专门留给邮件用比如mail.example.com。先创建 A 记录把mail指向服务器公网 IP然后建 MX 记录指向mail.example.com再给mail.example.com做 PTR 反向解析——PTR 是很多云厂商控制台里单独提供的功能没有 PTR 的话对方服务器做反向 DNS 校验时会直接降级你的信誉分。资源方面2 核 4G 内存是起步线ClamAV 扫描时内存很容易冲到 2G 以上1G 内存的机器不是跑不起来而是 Swap 会被打满整机响应变慢届时你分不清是邮件服务的问题还是系统资源不够。磁盘给 50G 起步邮件附件增长比你想得快。部署前需要确认的 DNS 记录如下记录类型主机记录记录值说明Amail服务器公网 IP必填MXmail.example.com优先级 10PTR公网 IPmail.example.com多数云需单独申请TXTmailvspf1...SPF 记录见第 4 章3.2 生成配置mailcow.conf 里值得手动确认的参数服务器上装好 Docker 和 Docker Compose 插件之后把项目拉下来执行配置生成脚本整个过程是向导式的。脚本的第一个问题会让你填主机名也就是mail.example.com这种格式这里填错后面所有证书申请都会跟着错。# 拉取项目源码 git clone https://github.com/mailcow/mailcow-dockerized cd mailcow-dockerized # 生成配置文件过程中会交互式询问主机名 ./generate_config.sh脚本跑完会在项目根目录生成mailcow.conf下一步是手动改几个关键参数。不要跳过这步直接启动容器默认时区是 UTC国内服务器不改成 Asia/Shanghai后面日志时间、邮件 Date 头全都差 8 小时排查问题的时候非常折磨。# 编辑 mailcow.conf按需修改以下参数 # MAILCOW_HOSTNAMEmail.example.com # 与 generate_config.sh 填写的保持一致 # TZAsia/Shanghai # 时区改为 Asia/Shanghai # HTTP_PORT80 # 默认即可如需改端口注意与防火墙同步 # HTTPS_PORT443 # 默认即可 # SKIP_LETS_ENCRYPTn # 有自有证书可设 y否则保持 nMAILCOW_HOSTNAME决定证书申请与生成 DKIM 记录时用的域名TZ影响全部容器内进程的时区SKIP_LETS_ENCRYPT在还没有正式域名或申请失败时可以临时设成y邮件功能不受影响只是 Web UI 会提示证书不可信。改完保存执行下面这段命令拉取镜像并启动全套容器# 拉取镜像并后台启动所有容器 docker compose pull docker compose up -d首次启动时要拉十几个镜像耗时取决于网络建议提前给 Docker 配置镜像加速。等容器全部进入 running 状态后浏览器访问https://服务器IP能打开登录页说明核心服务起来了。3.3 从 Web UI 到第一封外发邮件Mailcow 的初始管理员账号固定是admin初始密码不是写在文档里的而是随机生成后保存在mailcow.conf里。查密码执行下面这段命令# 查看 admin 账号初始密码 grep -i admin_pass mailcow.conf第一次登录后会强制改密码。进入后台后第一件事是创建域名在「配置 → 域名」里点新增填写你的域名并选择「添加域名并配置 MX」。Mailcow 会自动生成对应的 MX、SPF 记录列表照着填到 DNS 服务商那里即可这一步相当于把后台的元数据建好。域名创建后到「配置 → 邮箱」新增一个邮箱账号设置好密码。此时用任意邮件客户端配置 IMAP/SMTP——服务器地址填mail.example.comIMAP 端口 993 带 SSL、SMTP 端口 587 选 STARTTLS——就能收发信了。第一封外发邮件建议发给一个 Gmail 或 Outlook 邮箱同时做好垃圾箱的心理准备域名刚启用时信誉为零被拦的概率不低。具体怎么把信誉做起来看第 4 章和第 6 章。4. 上线别急着发信SPF/DKIM/DMARC 三件套与备份恢复4.1 让外面的世界信任你SPF、DKIM、DMARC 配置域名能收发信和域名不被判垃圾是两回事。SPF 声明哪些 IP 被授权发送该域名的邮件DKIM 给每封邮件做数字签名DMARC 告诉对方服务器验证失败时怎么处理三者缺一个都会被主流邮箱降级。Mailcow 后台的 DKIM 配置在「配置 → 域名 → 域名管理」里选中域名点 DKIM 按钮选择 2048 位密钥生成。生成后页面会显示一条 TXT 记录主机记录 값 形如dkim._domainkey记录值形如vDKIM1; krsa; pMIGf...把这串东西原样复制到 DNS 服务商。SPF 和 DMARC 我用下面这些记录直接照着填即可。记录类型主机记录值SPFTXTvspf1 mx ip4:服务器公网IP -allDMARCTXT_dmarcvDMARC1; pquarantine; ruamailto:adminexample.comSPF 里mx表示允许 MX 记录指向的服务器发送ip4:后面写死公网 IP-all表示除此之外都拒绝这是比较严格的策略如果后续有第三方邮件营销平台代发要额外加include:规则。DMARC 的pquarantine表示验证失败进垃圾箱等跑一段时间确认没有误拦再改成preject这样域名被伪造的概率会低很多。DNS 生效后建议做一次验证确保解析结果正确# 验证 MX、SPF、DKIM 解析是否已生效 dig MX mail.example.com dig TXT mail.example.com dig TXT dkim._domainkey.mail.example.com注意 DKIM 的查询域名是dkim._domainkey.mail.example.com不是裸域。DNS 传播一般几分钟到几小时不等没生效时别急着重启容器。4.2 备份、恢复与升级每台邮件服务器都需要三份后悔药邮件数据丢了没有后悔药这个概念所以备份要从上线的第一天就做。Mailcow 自带的备份脚本在helper-scripts/backup.sh它打的不是文件快照而是把 MySQL 数据、邮箱存储、Redis 数据这些 Docker 卷打包这是最省事的备份方式。建议配合 crontab 每晚跑一次备份文件至少保留 7 天。# 一键备份全部数据卷到 backup 目录并保留历史版本 ./helper-scripts/backup.sh -c /opt/backup-c参数指定备份输出目录脚本会按日期生成子目录。恢复时用-r参数指明备份目录脚本会把卷里的数据原样放回去。恢复前先docker compose down停掉全部容器避免数据写入冲突。升级是很多人不敢碰的一步其实 Mailcow 的更新脚本设计得已经把风险压到最低了。执行./update.sh前先把mailcow.conf里关键参数手抄一份同时确认备份目录空间充足。更新脚本会自动处理镜像拉取、数据库迁移和配置合并自定义修改要留意输出日志里有没有提示覆盖这也就是我前面强调用docker-compose.override.yml存自定义项的原因——默认配置覆盖不了它自然也就不会丢。5. 邮件服务器避坑手册25 端口、OOM 与 DKIM 不生效5.1 出站投递的三道坎下面这几类坑是我在多个生产环境里真实遇到的每一条都按「现象 → 原因 → 解决」拆开讲建议照着排查一遍。第一道坎25 端口出不去外发邮件全部超时。现象邮件发送队列越积越多Postfix 日志里全是connect to xxx[IP]:25: Connection timed out。原因国内大多云厂商默认封禁 25 端口出方向阿里云、腾讯云都要单独提工单解封而且解封通常只对已备案域名开放。解决先用nc -vz 对方邮件服务器IP 25测通不通确认被封就去云厂商控制台提交工单说明用途并承诺不发送垃圾邮件。要留意的是有些厂商解封的只是入方向 25出方向还要再确认一次否则你的服务器能收信但不能发信看上去像是配置问题实际是网络策略问题。第二道坎SPF 记录本身带坑。现象发给 Gmail 的邮件被拒退信内容提示SPF_PASS但DKIM_FAIL或者干脆出现在收件人垃圾箱。原因SPF 的 TXT 记录只能有一条如果同一条记录里重复出现多个ip4:或者-all与all同时存在对方解析时按严格模式判断就直接失败。解决用 SPF 记录生成器重新生成把mx、ip4:、include:按顺序排好最后以-all收尾。改完用dig TXT mail.example.com确认记录完整。第三道坎改了 DKIM 记录却不生效。现象DNS 上 DKIM 记录已经更新但邮件头里的Authentication-Results仍是旧签名。原因Rspamd 的 DKIM 密钥缓存在 Redis 里DNS 更新不会自动刷新缓存老签名还在被重复使用。解决改完 DKIM 后重启 Rspamd 容器并强制清 Redis 缓存。具体命令见下# 重启 Rspamd 容器强制重新加载密钥 docker compose restart rspamd # 清理 Redis 中与 DKIM 相关的缓存键 docker compose exec redis redis-cli DEL $(docker compose exec redis redis-cli KEYS *dkim* | tr \n )5.2 资源与配置的坑第四道坎ClamAV 内存冲到 3G容器被 OOM 杀掉。现象运行一段时间后docker compose ps里 clamav 容器显示 Restartingdmesg里出现Out of memory: Kill process日志尾部全是 ClamAV 的扫描记录。原因ClamAV 默认线程数偏多邮件附件多时同时解压扫描内存占用直接拉满1G/2G 内存的机器很容易触发内核 OOM。解决在项目根目录写docker-compose.override.yml给 clamd 容器加内存上限并降低最大线程数这是我的常用配置services: clamd: mem_limit: 2048m environment: - MAX_THREADS1MAX_THREADS1不是让 ClamAV 只用一个线程而是限制它单次扫描线程的并发量实际性能损失不大内存压力却降得立竿见影。加完docker compose up -d重新创建容器即可生效。第五道坎收件人看到邮件时间差 8 小时。现象同一封邮件Webmail 里显示时间正常但在 Outlook 里看日期头是 UTC 时间。原因两个层面服务器时区没设为 Asia/Shanghai并且 Dovecot 投递时没有正确写入本地时区头。解决mailcow.conf里把TZAsia/Shanghai改好然后进 Web UI 的「系统 → 设置」把默认时区也改成 Asia/Shanghai最后重启 postfix 和 dovecot 容器。如果你在部署时就设置了正确的TZ这步可以完全跳过。6. 进阶怎么确认自己的邮件真的进了对方收件箱部署完成只是开始邮件服务器上线后真正见真章的是投递率。我的习惯是把第 4 章的三件套配好并确认生效后先给mail-tester.com发一封测试邮件它会从外部视角检查发送方 IP 的 PTR、SPF、DKIM、DMARC 各项评分给一个 10 分制的分数。8 分以下说明还有硬伤9 分以上基本具备正常投递的资格。同时把域名加到 Google Postmaster Tools 里这个后台能看到 Gmail 方向的送达率、垃圾邮件率、IP 信誉三个核心指标比到处问“为什么进垃圾箱”可靠得多。Mailcow 的 Web UI 自带一个「诊断」页面位置在「系统 → 诊断」点运行后会从本机视角测试 25 端口连通性、PTR 记录、证书有效性等基础项。这个诊断只能证明你的服务端口都通不能证明外部信任你所以它适合做排障起点而不是终点。有段时间我把 DKIM 密钥轮换了一轮改完 DNS 记录后直接去跑 mail-tester分数从 9.5 掉到 6排查了半天才发现是密钥轮换后 Rspamd 缓存没清透DNS 那边其实已经生效了走了一遍第 5 章那个 Redis 清理命令再测试才回到正常。从那以后我每次涉及 DNS 或密钥的变更强制走一遍固定的验证顺序先dig确认解析再重启 rspamd 容器清 Redis最后用外部邮件地址实际收发各一封确认投递状况。这套流程记录得越详细越容易在后续排查中定位问题域。希望帮到你。本文还有配套的精品资源点击获取