自建邮件服务器最大的吸引力，是可以自行掌握邮箱账户、邮件存储、域名、反垃圾策略和 Webmail 等核心能力。但真正部署到家庭宽带环境后，经常会遇到一个非常现实的问题：

邮件可以正常接收，却无法向 Gmail、Proton Mail、QQ 邮箱等外部邮件服务器发送。

问题通常并不出在 Mailcow、Postfix 或 DNS，而是互联网接入商限制了出站 TCP 25 端口。

SMTP2GO 这类 SMTP Relay 服务，可以在不放弃自建 Mailcow 的情况下解决这个问题。

---

一、为什么自建邮件服务器会遇到 TCP 25 问题

传统电子邮件服务器之间主要通过 SMTP TCP 25 端口通信。

例如：

Mailcow
   ↓ TCP/25
Gmail MX

当一封邮件需要发送到：

user@gmail.com

Postfix 会查询 gmail.com 的 MX 记录，然后直接连接 Google 的邮件服务器：

gmail-smtp-in.l.google.com:25

在服务器机房、VPS 等环境中，这通常可以正常工作。

但是很多家庭宽带为了减少垃圾邮件、感染木马的设备发送 Spam 等问题，会限制：

Outbound TCP/25

于是 Postfix 日志可能出现：

connect to xxx:25: Connection timed out
status=deferred

邮件本身并没有丢失，而是不断留在 Postfix 队列中等待重试。

此时即使：

• MX 正确
• DKIM 正确
• SPF 正确
• TLS 正确
• Mailcow 工作正常

仍然无法完成外部投递。

---

二、SMTP2GO 的作用是什么

SMTP2GO 可以理解成一个专业的上游 SMTP 中继服务器。

原来的邮件路径是：

Mailcow
   ↓ TCP/25
收件服务器

加入 SMTP2GO 后变成：

Mailcow
   ↓ TCP/587
SMTP2GO
   ↓ TCP/25
收件服务器

也就是说，家庭服务器不再直接连接全球邮件服务器的 25 端口。

Mailcow 只需要连接：

mail.smtp2go.com:587

然后由 SMTP2GO 完成真正的互联网邮件投递。

由于家庭宽带通常不会封锁 TCP 587，因此可以绕过出站 25 端口限制。

---

三、SMTP2GO 并不会取代 Mailcow

这是整个架构中最重要的一点。

使用 SMTP2GO 后，Mailcow 仍然是完整的邮件服务器。

例如：

<mail.example.com>

仍然负责：

• 邮箱账户管理
• 邮件存储
• IMAP
• POP3
• SMTP Submission
• Webmail
• Postfix
• Dovecot
• Rspamd
• ClamAV
• DKIM
• 本地域邮件投递
• 接收互联网邮件

SMTP2GO只负责其中一件事：

把需要发送到外部邮件域的邮件继续投递出去。

因此两者关系是：

Mailcow = 邮件服务器本体
SMTP2GO = 外发 SMTP Relay

---

四、收邮件的路径完全不变

假设邮箱域名为：

<your-domain.example>

邮件服务器为：

<mail.your-domain.example>

DNS 中仍然可以配置：

<your-domain.example>
MX 10 <mail.your-domain.example>

外部服务器发送邮件时：

Gmail
   ↓ 查询 MX
<mail.your-domain.example>
   ↓ TCP/25
Mailcow
   ↓
Dovecot
   ↓
Mailbox

SMTP2GO完全不参与这一过程。

所以加入 SMTP Relay 并不意味着把整个邮件系统托管给第三方。

---

五、外发邮件时发生了什么

假设一个客户端发送：

sender@<your-domain.example>

到：

recipient@gmail.com

完整过程可以分成几步。

1. 客户端把邮件交给 Mailcow

例如 Thunderbird：

Thunderbird
   ↓ SMTPS 465
Mailcow/Postfix

或者：

Thunderbird
   ↓ SMTP Submission 587
Mailcow/Postfix

客户端首先使用自己邮箱的用户名和密码登录 Mailcow。

这一阶段和 SMTP2GO 无关。

---

2. Postfix 将邮件放入队列

Postfix 接收邮件后，会生成一个 Queue ID，例如：

ABC123DEF456

此时邮件由本机 Postfix 管理。

---

3. Postfix 判断邮件应该走哪条路

如果收件人也是：

@<your-domain.example>

Mailcow知道这是本地域，于是直接：

Postfix
   ↓ LMTP
Dovecot
   ↓
本地邮箱

不会经过 SMTP2GO。

如果收件人是：

@gmail.com
@proton.me
@qq.com
@outlook.com

则属于外部域。

此时可以通过 Mailcow 的 Sender-dependent Transport 将：

@<your-domain.example>

的外发邮件指向：

[mail.smtp2go.com]:587

---

六、为什么配置成 [mail.smtp2go.com]:587

典型配置目标为：

[mail.smtp2go.com]:587

其中：

587

是 SMTP Submission / Relay 常用端口。

方括号：

[mail.smtp2go.com]

则告诉 Postfix：

直接连接这个主机，不要再对它执行 MX 查询。

最终只需要：

DNS 查询 mail.smtp2go.com
        ↓
获得 SMTP2GO IP
        ↓
连接 TCP/587

---

七、Mailcow 如何获得 SMTP2GO 的发送权限

SMTP2GO通常提供独立的 SMTP 凭据：

SMTP Server:
mail.smtp2go.com

Port:
587

Username:
<smtp-user>

Password:
<smtp-password>

这组用户名和密码与 Mailcow 邮箱密码不是一回事。

两套认证应该分开理解：

邮件客户端
   ↓
邮箱用户名/密码
   ↓
Mailcow

以及：

Mailcow
   ↓
SMTP2GO SMTP Username/Password
   ↓
SMTP2GO

因此即使邮箱里有几十个用户，Mailcow也可以统一通过同一套 SMTP2GO Relay 凭据完成外发。

---

八、TLS 在其中扮演什么角色

Mailcow 连接 SMTP2GO 的典型过程为：

EHLO
STARTTLS
AUTH
MAIL FROM
RCPT TO
DATA

首先连接：

mail.smtp2go.com:587

SMTP2GO返回：

250-STARTTLS
250-AUTH

Postfix随后执行：

STARTTLS

双方建立 TLS 加密连接。

正常日志可能看到：

Trusted TLS connection established
TLSv1.3

随后才进行 SMTP AUTH。

因此：

Mailcow ↔ SMTP2GO

这一段传输不会以明文经过互联网。

---

九、为什么还需要给 SMTP2GO 配置 DNS

SMTP2GO需要确认：

当前账户确实有权代表 <your-domain.example> 发信。

否则任何注册用户都可以伪造其他公司的域名发送邮件。

因此通常需要增加若干 DNS 记录，例如：

<return-subdomain>.<your-domain.example>
    CNAME
return.smtp2go.net

<selector>._domainkey.<your-domain.example>
    CNAME
dkim.smtp2go.net

以及可选的：

<link-subdomain>.<your-domain.example>
    CNAME
track.smtp2go.net

这些记录主要解决的是：

• 域名所有权验证
• DKIM
• Return-Path
• Bounce handling
• 邮件身份验证
• Tracking domain

它们并不是邮件路由记录。

---

十、DNS 和 SMTP 路由必须区分开

这是非常容易混淆的一点。

Mailcow 中的 Transport

决定：

邮件发送到哪里

例如：

<your-domain.example>
→ [mail.smtp2go.com]:587

这是路由配置。

---

DNS 中的 SMTP2GO 记录

决定：

SMTP2GO 是否获得该域名授权

以及：

接收方如何验证邮件

这是身份与认证配置。

---

因此：

Mailcow Transport

解决：

去哪里发。

而：

DNS

解决：

有没有资格代表这个域名发。

---

十一、SMTP2GO 的 DKIM 是怎么工作的

假设 SMTP2GO 使用：

<selector>

作为 DKIM selector。

邮件中可能出现：

DKIM-Signature:
d=<your-domain.example>;
s=<selector>;

Gmail收到邮件以后，会查询：

<selector>._domainkey.<your-domain.example>

DNS返回：

CNAME → dkim.smtp2go.net

然后 Gmail取得 DKIM 公钥，验证邮件签名。

验证成功后，可以证明：

这封邮件是由获得 <your-domain.example> 授权的发送基础设施签名的。

---

十二、为什么 Mailcow 原来的 DKIM 不需要删除

Mailcow本身可能已经有类似：

dkim._domainkey.<your-domain.example>

的记录。

SMTP2GO则可能使用：

<selector>._domainkey.<your-domain.example>

由于 selector 不同：

dkim

与：

<selector>

并不冲突。

同一个域名完全可以存在多个 DKIM selector。

因此通常没有必要为了 SMTP2GO 删除 Mailcow 原来的 DKIM。

---

十三、Return-Path 的作用

SMTP邮件实际上存在两个比较容易混淆的“发件人”。

用户看到的是：

From:
sender@<your-domain.example>

SMTP底层还有：

MAIL FROM

后者通常最终与：

Return-Path

相关。

它主要用于：

• 退信
• SPF
• Bounce
• Delivery Status Notification

SMTP2GO通常会使用一个专门的 Return-Path 子域。

通过：

<return-subdomain>.<your-domain.example>
→ return.smtp2go.net

可以让这一部分仍然处于自己的域名体系之下，同时把具体处理委托给 SMTP2GO。

---

十四、邮件发送成功有两个阶段

Postfix 日志出现：

relay=mail.smtp2go.com:587
dsn=2.0.0
status=sent
250 OK

意味着：

SMTP2GO已经成功接收这封邮件。

然后 Postfix 会：

removed

从本地队列删除。

但是这并不一定等价于：

Gmail 已经最终收件。

责任已经从：

Mailcow

转移到了：

SMTP2GO

SMTP2GO随后才会：

查询目标域 MX
      ↓
连接目标服务器 TCP/25
      ↓
尝试投递

因此有两个不同的成功状态：

Mailcow status=sent
= Mailcow → SMTP2GO 成功

以及：

SMTP2GO Delivered
= SMTP2GO → 最终目标服务器成功

如果最终服务器暂时不可用，SMTP2GO会负责排队和重试。

---

十五、SMTP2GO 还减少了本地服务器的外发负担

直接投递时，如果 Gmail暂时不可用：

Mailcow
   ↓
Gmail:25
失败
   ↓
Postfix Queue
   ↓
过一段时间重试
   ↓
再次连接

这些事情全部由自建服务器承担。

使用 SMTP2GO后：

Mailcow
   ↓
SMTP2GO:587
   ↓
250 OK

Mailcow可以立即结束任务。

之后：

SMTP2GO
   ↓
Gmail
失败
   ↓
SMTP2GO自己的队列
   ↓
SMTP2GO负责重试

因此以下工作也被转移到了第三方：

• 外部 SMTP 重试
• 大规模 MX 查询
• 目标服务器限速
• Bounce 管理
• 公网发送 IP
• IP Reputation
• 外发 TCP 25

---

十六、服务器负荷主要仍然在哪里

使用 SMTP2GO并不会让 Mailcow变成一个简单的转发器。

Mailcow仍然需要长期运行：

Postfix
Dovecot
Rspamd
ClamAV
SOGo
MariaDB
Redis
Nginx
Unbound

其中尤其是：

ClamAV
Rspamd
数据库
Webmail
邮箱存储

会产生持续的 CPU、内存和磁盘负载。

SMTP2GO承担的是外部投递阶段的工作，而这些资源消耗发生在 SMTP2GO自己的服务器上。

因此可以概括为：

本地 Mailcow
→ 邮件系统主体负荷

SMTP2GO
→ 互联网外发投递负荷

---

十七、隐私方面需要知道什么

SMTP Relay并不是端到端加密通道。

当前结构是：

Mailcow
   ↓ TLS
SMTP2GO
   ↓ TLS
最终邮件服务器

TLS可以防止运营商、路由器和网络中间节点直接读取邮件。

但是 SMTP2GO本身是第一段 TLS 的终点。

因此从技术上讲，它需要能够处理：

• 发件人
• 收件人
• Subject
• 邮件正文
• HTML
• 附件
• 邮件 Header

所以使用第三方 SMTP Relay本质上意味着：

将外发邮件处理过程中的一部分信任交给第三方服务商。

对于普通个人邮件、服务器通知、账号邮件和日常通信，这是常见的邮件架构。

如果邮件内容属于必须保证中继服务商也无法读取的高度敏感信息，则需要另外使用：

OpenPGP

或者：

S/MIME

进行真正的端到端内容加密。

---

十八、SMTP2GO 故障时会发生什么

如果 SMTP2GO暂时不可用：

Mailcow
   ↓
mail.smtp2go.com:587
   ×

Postfix不会立即丢弃邮件，而是将其置为：

deferred

然后按照自己的队列策略重试。

而收信仍然可以继续：

Internet
   ↓
<mail.your-domain.example>:25
   ↓
Mailcow

本地域邮件同样正常：

user1@<your-domain.example>
        ↓
Mailcow
        ↓
user2@<your-domain.example>

因此 SMTP2GO故障主要影响：

向外部域发送邮件

不会导致整个 Mailcow失效。

---

十九、这套架构适合什么场景

这种方式特别适合：

• 家庭宽带部署 Mailcow
• ISP 封锁 Outbound TCP/25
• 动态或住宅公网 IP
• 邮件量较低
• 希望继续自行保存邮箱数据
• 希望保留自己的 IMAP、SMTP、Webmail
• 不希望把整个邮箱迁移到 Gmail 或 Microsoft 365
• 只想把困难的公网外发部分交给专业服务商

架构最终可以保持为：

                 收信
──────────────────────────────

Internet
   ↓ TCP/25
<mail.your-domain.example>
   ↓
Mailcow
   ↓
Mailbox


                 外发
──────────────────────────────

Client / Webmail / Application
   ↓
Mailcow
   ↓ TCP/587 + TLS + AUTH
SMTP2GO
   ↓ TCP/25
Destination MX

---

二十、核心理解

SMTP2GO并不是把自建 Mailcow替换掉。

它解决的是自建邮件服务器中一个非常具体的问题：

无法可靠地从住宅网络直接向全球邮件服务器发送 SMTP 邮件。

因此整个方案可以用三句话概括：

MX
→ 告诉互联网：邮件由 Mailcow 接收。

Mailcow Sender-dependent Transport
→ 告诉 Postfix：外发邮件交给 SMTP2GO。

SMTP2GO DNS 验证记录
→ 告诉收件服务器：SMTP2GO获得了该域名的发送授权。

最终形成一种比较实用的折中：

邮箱、邮件数据、收信和内部处理继续自行掌控；公网 SMTP 外发交给专业 Relay 服务处理。

对于受家庭宽带 TCP/25 限制的自建 Mailcow环境，这是一种结构清晰、改动较小、维护成本较低的解决方案。