自建邮件服务器真正困难的部分，往往不是“让服务跑起来”。
安装 Mailcow、创建邮箱、部署 Webmail、接收外部邮件，这些工作虽然复杂，但通常都有相对明确的配置路径。真正进入长期运行阶段以后，更难回答的是另一组问题：
- 邮件究竟是不是按照预期路径发送？
- SMTP Relay 是否真的生效？
- SPF、DKIM、DMARC 是“看起来配置正确”，还是收件方实际验证通过？
- 反向代理之后还能不能记录真实客户端 IP？
- 公网扫描是否代表服务器正在遭受攻击？
- 邮件服务器是否存在 Open Relay、认证暴力破解、队列堆积或性能瓶颈？
- 家庭公网 IP 不固定，会不会影响域名信誉？
- 一个长期运行的实例，究竟什么时候才可以认为“已经稳定”？
一次完整的 Mailcow 只读审计和真实邮件投递测试，可以把这些问题逐一回答。
一、审计原则：先证明现状，而不是先修改配置
邮件服务器非常不适合采用“看到一个警告就改一点”的排障方式。
Postfix、Dovecot、Rspamd、Nginx、DNS、TLS、DKIM、DMARC、反垃圾系统以及网络地址转换之间存在大量相互依赖。一个看似合理的修改，可能解决一个问题，同时制造另一个问题。
因此审计采用了一个简单原则：
只读。
整个过程中不执行：
- 配置修改；
- Docker 容器重启；
- 服务 reload；
- 邮件队列 flush；
- DNS 修改；
- 数据库写入；
- 防火墙调整；
- 主动制造故障；
- 为测试而临时改变邮件流向。
只读取：
- Docker 服务状态；
- Postfix、Dovecot、Rspamd、Nginx 等日志；
- 当前生效配置；
- DNS 记录；
- TLS 证书；
- 邮件队列；
- 网络监听状态；
- 资源使用情况；
- 实际外发邮件的原始邮件头。
这样得到的结果描述的是系统当前真实工作方式，而不是“经过测试修改后的状态”。
二、典型家庭 Mailcow 架构
审计对象采用的是一种比较典型的家庭自建邮件架构。
整体可以抽象为：
Internet
│
▼
Home Router / NAT
│
├── SMTP / Submission / IMAPS
│ │
│ ▼
│ Mailcow
│
└── HTTPS
│
▼
Reverse Proxy
│
▼
Mailcow Web UI
外发邮件则采用：
Mailcow
│
▼
External SMTP Relay
│
▼
Gmail / Outlook / Proton Mail / Other MX
这种设计有一个很重要的特点：
收信和邮件数据仍然由自己的 Mailcow 控制，但公网外发交给专业 SMTP Relay。
对于家庭宽带来说，这是非常实际的一种架构。
很多运营商会限制 TCP 25 出站，家庭公网 IP 也通常不具备适合直接投递大型邮件服务商的长期 IP Reputation、PTR 和网络属性。
SMTP Relay 可以解决这一层问题，而域名、邮箱、邮件数据、DKIM 身份和管理权仍然可以保持独立。
三、公网邮件服务器一定会被扫描
邮件服务器暴露到公网以后，很快就会看到大量陌生连接。
SMTP 日志中常见：
postscreen CONNECT
Web 日志中可能出现：
/wp-login.php
/xmlrpc.php
/.env
/.git/config
/.aws/credentials
IMAP、Submission、SMTPS 也会出现只连接几秒便断开的客户端。
其中一些来源甚至带有明显的互联网测绘主机名，例如：
- 网络安全研究机构；
- Internet-wide scanner；
- 资产搜索平台；
- 自动漏洞扫描器。
这类连接很容易让第一次维护公网服务的人产生一种错觉：
“服务器是不是已经被攻击了？”
实际上需要进一步区分。
扫描不等于入侵
审计中观察到的大部分公网访问属于：
- 端口发现；
- SMTP 服务识别；
- STARTTLS 能力探测；
- Web 技术栈识别；
- WordPress 路径扫描；
- 配置文件泄漏扫描；
- Internet-wide measurement。
真正更值得关注的则是：
- SMTP AUTH 连续失败；
- IMAP 密码爆破；
- 成功登录来自未知公网来源；
- Open Relay；
- Web 管理界面认证绕过；
- 敏感文件返回 200；
- SMTP 队列中出现异常外发；
- 被入侵账户大量发送邮件。
在这次审计中，没有发现这些高风险证据。
因此：
“公网扫描很多”本身不是邮件服务器异常。
它只是公开服务进入互联网之后的正常背景噪声。
四、不要用粗糙的正则统计“攻击 IP”
日志分析中还有一个非常容易出现的错误。
例如：
grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}'
表面上是在提取 IPv4。
但现代 Web 日志中经常包含：
Chrome/xxx.0.0.0
于是浏览器版本号也会被错误统计成“IP”。
最终可能得到：
xxx.0.0.0
出现数百次，然后被误认为最大攻击源。
正确方式应该根据日志类型提取真实客户端字段：
- Postfix：
CONNECT from [IP] - Dovecot：
rip= - Nginx：access log 的客户端地址字段
- Netfilter：明确的 ban/fail 来源
安全分析中，“字段语义”远比简单正则重要。
五、SMTP Relay 是否真正接管了外发？
Mailcow 配置 SMTP Relay 以后，不能只看管理界面里有没有一条 Relay 配置。
真正需要确认的是：
Mailcow
↓
Relay Host
↓
250 OK
同时还要确认：
Relay unavailable
↓
Postfix defer / queue
而不是：
Relay unavailable
↓
Fallback
↓
Direct delivery to Gmail / Outlook / Proton MX
此次审计通过 Postfix 当前配置和实际日志确认：
- 外发邮件使用外部 SMTP Relay；
- SMTP AUTH 已启用；
- TLS 连接正常；
- Relay 返回
250 OK； - 没有配置自动 MX fallback；
- Relay 临时不可用时，邮件应保留在 Postfix 队列并 defer；
- 当前邮件队列为空。
早期日志中仍然出现过直接连接 Gmail、Proton 等目标 MX 的记录。
但进一步按照 Queue ID 和时间线分析后发现，那些属于切换 SMTP Relay 以前遗留下来的旧邮件队列重试。
新的邮件已经全部走 Relay。
这说明一个重要原则：
日志必须结合时间线分析。
旧错误存在于日志中，不代表当前配置仍然错误。
六、SPF 不能只看根域 TXT
很多邮件配置检查会直接运行：
TXT example.com
然后看到类似：
v=spf1 a mx ip4:x.x.x.x ~all
如果其中没有：
include:某SMTP服务商
便得出：
SMTP Relay 的 SPF 没有配置。
这种判断并不一定正确。
现代 SMTP Relay 经常使用独立的 Return-Path 子域。
例如最终邮件可能变成：
From:
user@example.com
Return-Path:
bounce-xxxxx@relay-id.example.com
SPF 检查的是 SMTP Envelope From，也就是 Return-Path 对应的域，而不一定是用户看到的 Header From。
因此可能出现：
Header From:
example.com
SPF authentication domain:
relay-id.example.com
只要后者是前者的子域，并且符合 DMARC alignment 规则，就可以正常通过认证。
所以 SPF 是否真正正确，最终应该看：
收件服务器生成的 Authentication-Results。
七、真实 Gmail 邮件头给出了最终答案
完成服务器侧审计以后，又实际发送了一封普通测试邮件到 Gmail。
测试内容非常普通，没有附件、营销内容或复杂 HTML。
Gmail 收件端产生的原始邮件头明确给出了：
spf=pass
dkim=pass
dmarc=pass
这比任何本地 DNS 检查都更有意义。
因为这代表：
真实外部邮件服务商已经实际完成验证。
SPF
Gmail 看到的 Envelope From 使用了 SMTP Relay 创建的专用 Return-Path 子域。
同时 Gmail 明确确认：
spf=pass
这证明：
- SMTP Relay 的 Sender Domain 配置已经生效；
- 专用 Return-Path DNS 工作正常；
- Relay 实际出口 IP 被 SPF 正确授权；
- SPF authentication domain 正常。
DKIM
邮件中出现了多个 DKIM 签名。
其中包括：
d=example.com
由本地 Mailcow 添加的签名；
另一个：
d=example.com
由 SMTP Relay 为客户域名追加的签名；
以及 Relay 服务商自己的服务域 DKIM。
Gmail 对这些签名均返回：
dkim=pass
这说明多 DKIM 签名本身并不是冲突。
只要每个签名独立有效，它们可以同时存在。
尤其重要的是：
d=example.com
与：
From: user@example.com
完全一致，因此 DKIM alignment 直接成立。
DMARC
最终：
dmarc=pass
这意味着至少一个经过验证的 SPF 或 DKIM 身份与 Header From 满足 DMARC alignment。
因此邮件完整通过了：
SPF PASS
DKIM PASS
DMARC PASS
这已经属于完整的端到端验证。
八、进入 Gmail Inbox 说明了什么？
这封真实邮件最终进入了 Gmail 的正常收件箱，而不是 Spam。
这是一个积极信号。
它至少证明在这一次真实投递中：
- Gmail 接受了邮件；
- 邮件认证全部正常；
- 没有因为当前发送路径直接被判定为 Spam；
- SMTP Relay 的当前出口信誉足以正常投递；
- 邮件内容没有触发明显垃圾邮件规则。
但这不能理解为：
“一封进 Inbox，域名就获得了很高的信誉。”
邮件信誉是长期行为。
大型邮件提供商通常会综合观察：
- Domain Reputation；
- IP Reputation；
- SPF / DKIM / DMARC 稳定性；
- 用户 Spam 投诉；
- 退信率；
- 发信量变化；
- 历史发送行为；
- 邮件内容；
- 用户互动；
- 恶意链接或附件历史。
因此更准确的说法是：
技术身份链已经建立正确，域名具备自然积累正常发信历史的基础。
九、域名信誉与 SMTP Relay IP 信誉是两回事
SMTP Relay 架构下，至少存在两层信誉。
第一层：发送 IP Reputation
真正与 Gmail 建立 SMTP 连接的是 Relay 的公网 IP。
因此这部分 IP Reputation 主要由 Relay 服务商维护。
家庭宽带自己的公网 IP 不需要承担主要的外发 IP Reputation。
第二层：Domain Reputation
邮件中仍然包含：
From: user@example.com
并且 DKIM：
d=example.com
DMARC：
header.from=example.com
均正常对齐。
因此 Gmail 仍然能够明确识别：
这封邮件代表的是 example.com。
也就是说：
使用 SMTP Relay 并不会阻止自己的域名建立 Domain Reputation。
这对家庭自建邮件服务器尤其重要。
可以把最困难的公网 IP 信誉层交给 Relay，同时继续积累自己的域名身份历史。
十、家庭公网 IP 不固定怎么办？
家庭宽带公网 IPv4 可能偶尔变化。
如果 SMTP Relay 已经承担外发，则公网 IP 变化主要影响：
- MX 收信入口；
- A 记录；
- HTTPS；
- IMAP；
- SMTP 接收；
- Certificate Challenge；
- DNS 中硬编码的 IP。
而不是主要影响 SMTP Relay 的外发 Reputation。
如果 SPF 中存在：
ip4:旧公网IP
那么公网 IP 改变后需要特别注意：
a
mx
会随着 DNS A 记录更新；
但：
ip4:x.x.x.x
不会自动改变。
如果旧地址以后分配给其他用户，那么旧 ip4: 将继续授权该地址代表域名发送邮件。
因此人工公网 IP 更新流程中应该加入：
WAN IP
→ A records
→ MX resolution
→ SPF ip4
→ SMTP/IMAP/HTTPS verification
对于一年才偶尔发生一次的公网 IP 变化，没有必要为了这一点强行部署复杂 DDNS。
简单、明确的人工流程反而更容易维护。
十一、反向代理与真实客户端 IP
Mailcow Web UI 经 Nginx 等反向代理以后，还需要考虑：
X-Forwarded-For
X-Real-IP
real_ip_header
real_ip_recursive
TRUSTED_PROXIES
如果配置错误，Mailcow 可能只看到反向代理服务器的内网地址。
此次审计中，实际日志能够看到公网扫描来源，因此真实客户端 IP 转发链已经工作。
早期审计一度把较大的 RFC1918 trusted proxy 范围判定为中等风险。
进一步结合：
- Nginx
real_ip_recursive实际行为； - 公网只有反向代理入口；
- Mailcow Web backend 没有公网 DNAT；
- LAN 属于可信家庭网络；
最终将其降级为：
Informational / optional hardening
也就是说：
将 TRUSTED_PROXIES 收窄为单一反向代理地址是更漂亮的配置，但并不存在已经证实的公网安全漏洞。
这是安全审计中另一个很重要的原则：
“可以更严格”不等于“当前存在漏洞”。
十二、TLS 证书也需要检查“续期链”，而不仅仅是有效期
只运行：
openssl s_client
确认当前证书没有过期还不够。
真正需要知道的是：
谁签发？
谁续期？
谁部署？
部署到哪里？
续期后哪些服务 reload？
此次审计最终确认了一条完整链路：
ACME timer
↓
Certificate renewal
↓
Reverse Proxy
↓
Deploy hook
↓
Mailcow certificate directory
↓
Nginx / Postfix / Dovecot reload
并且代理节点和 Mailcow 当前使用的公开证书内容一致。
这比单纯看到：
expires in 80 days
更有意义。
十三、性能方面没有必要过度优化
邮件服务器中比较显眼的资源消费者通常包括：
- ClamAV；
- Rspamd；
- MySQL；
- SOGo；
- Redis；
- Dovecot。
其中 ClamAV 占用接近 1 GiB RAM 并不罕见。
如果：
- 系统仍有大量 Available Memory；
- 没有 Swap Thrashing；
- 没有 OOM；
- 容器没有重启；
- CPU 负载低；
- 队列正常；
- 邮件延迟正常；
那么仅仅因为某个容器“看起来用了很多内存”，并不能判定性能异常。
磁盘同理。
例如文件系统使用率超过 80%，如果仍然有接近 TB 级别的实际可用空间，并且增长速度稳定，就与一个只剩几 GB 的小磁盘完全不是一个风险等级。
容量监控应该同时考虑：
百分比
+
绝对剩余容量
+
增长速度
而不是只看一个百分数。
十四、最终审计结果
经过服务器侧只读审计和真实外部邮件验证，最终状态可以归纳为：
Mailcow services HEALTHY
Inbound SMTP HEALTHY
IMAP HEALTHY
Rspamd HEALTHY
ClamAV HEALTHY
SMTP Relay VERIFIED
SMTP AUTH VERIFIED
TLS VERIFIED
Relay failure behavior VERIFIED
MX fallback NONE
SPF PASS
DKIM PASS
DMARC PASS
DMARC alignment PASS
Gmail delivery INBOX
Open relay NOT OBSERVED
AUTH brute force NOT OBSERVED
Performance bottleneck NOT OBSERVED
仍然存在的一些事项，例如：
- trusted proxy 范围还能进一步缩小；
- 可以定期观察容量；
- 可以保留恢复演练；
- 可以记录 SMTP Relay 的账户级 DNS 配置；
都属于信息项或运维完善，而不是当前故障。
因此最终可以归类为：
CURRENT STATUS:
HEALTHY WITH INFORMATIONAL ITEMS
十五、自建邮件服务器真正的“完成”是什么？
自建邮件服务器是否完成，并不能只看：
docker compose up -d
也不能只看：
能登录 Webmail
甚至不能只看：
能收到邮件
真正进入稳定可用状态，至少应该能够回答：
外发路径是什么？
失败以后邮件去哪？
SPF 是否真正 PASS？
DKIM 是否真正 PASS？
DMARC 是否真正 PASS？
公网扫描有没有突破认证？
邮件队列是否健康？
真实客户端 IP 是否保留？
TLS 是否能够持续自动续期？
最终邮件能否进入主流服务商 Inbox？
当这些问题都有真实日志、DNS、配置和收件服务器邮件头作为证据以后，邮件服务器才从：
“可以运行的实验环境”
真正进入：
“能够长期使用的互联网邮件系统”。
而在家庭网络环境里，“完全自己承担所有环节”并不是唯一正确答案。
把邮箱账户、数据、域名、收信、过滤和管理权掌握在自己手中，同时让专业 SMTP Relay 承担最困难的公网发信出口，是一种相当务实的架构。
真正重要的不是每一个数据包都必须由自己的公网 IP 发出，而是：
邮件身份仍然属于自己的域名，数据仍然由自己的服务器掌握，并且整个系统能够以符合现代邮件生态要求的方式可靠运行。