在阿里云 ECS 上自建邮件服务，很多人都会踩到同一个坑。Postfix 或 Sendmail 配置好了，发信却一直超时，日志里反复出现 connection timed out。查到最后才发现，云服务器默认屏蔽了出站 25 端口。各家邮件服务商对云主机大多有类似限制，原因很直接：云主机成本低，IP 可以快速更换，一旦被木马控制，就容易变成垃圾邮件的发送源。
为什么默认封禁 25 端口
SMTP 协议默认用 25 端口投递邮件。新购买的 ECS 实例默认限制这个端口的出站访问，目的是保护整个网络的邮件信誉。限制只针对出站连接，入站 25 端口一般不受影响，所以服务器仍能收信，只是不能直接把邮件投递到外部邮件服务器。
解封要过审核。平台会先确认你的使用场景合理、发送量可控，还会看你有没有基本的邮件安全配置。这几项直接决定申请能否通过。
申请前需要准备什么
提交前把下面几项补齐，能减少因材料不全被退回的次数。
- 账号认证：确认阿里云账号已完成实名认证。企业用户最好用企业认证主体提交，和实际业务主体保持一致。
- 业务说明：写清楚邮件用途，是订单通知、注册验证码、系统告警还是营销邮件，并估算每天的发送量。
- 域名与 DNS：发信域名需要配置 SPF 记录。DKIM 签名和 DMARC 策略最好也一起配上，平台核对时会看这些记录。
- 反向解析：服务器公网 IP 设置 PTR 记录，并让它和发信域名对应。这一项做好，邮件送达率通常会明显改善。
- 退订机制：营销邮件需要提供退订链接，投诉和退信也要及时处理，不能放着不管。
申请流程
端口解封申请一般通过控制台的工单系统提交。入口和表单字段可能随版本调整，以页面显示为准。大致流程如下：
- 登录控制台，进入工单管理，或直接搜索“25端口解封”找到对应入口。
- 选择 ECS 实例所在的地域，填写实例 ID 和公网 IP。
- 如实写明业务场景、发信方式、日发送量和收件人来源。收件人来源要写具体，例如“用户注册时留下的邮箱”，不要只写“用户”。
- 提交后等待审核。审核期间不要改动邮件配置，平台需要按当前状态核对。
- 审核通过后，先用 telnet 或 nc 测试外部 25 端口是否连通，连通后再做正式发信测试。
审核时长因情况而异。有的当天就能通过，有的要补充材料后再审。所以申请后多久生效，主要取决于补材料的速度。首次提交时把用途讲清楚，通常最省时间。“用于群发”这类说法容易被当成营销风险，换成“订单确认邮件，只发给下单用户”这样的具体描述会好很多。
申请被拒的常见原因
解封失败多数是材料和场景对不上，和技术关系不大。常见情况有几种：实例刚开通不久就申请大批量发信；发信域名没有配置 SPF，或者有过投诉记录；业务描述太笼统；服务器之前出现过异常外发。
被驳回后，先看工单里的反馈，针对性地补材料。反复提交同样的内容没有用，还可能拖慢后续审核。
案例：小电商的发信改造
一个小型电商团队在阿里云 ECS 上自建 Postfix，用来发送订单确认和物流通知。上线第一天，邮件队列大量堆积，日志显示连接外部 25 端口超时。团队先怀疑是 Postfix 配置有问题，反复修改 main.cf 都没有效果。直到用 telnet 测试，才确认端口被限制。
之后他们做了三件事：给发信域名补充 SPF 和 DKIM 配置，设置 PTR 反向解析，并在工单里写明只发交易类邮件，日发送量约两千封，收件人都是用户主动注册时留下的邮箱。两个工作日后解封通过。团队随后把验证码和营销邮件拆到不同的发信通道，单个 IP 承担的风险就小了。材料写得越具体，来回沟通就越少。
替代方案：不一定非要解封 25 端口
如果只发交易类通知，或者不想长期维护邮件服务器，用邮件推送服务更省事。阿里云邮件推送（DirectMail）提供 SMTP 和 API 两种接入方式。SMTP 可以走 465 或 587 端口，API 走 HTTPS，两者都不依赖 25 端口。发信信誉和退信处理也由平台负责。验证码、订单通知这类场景，选它通常更稳。
如果一定要自建，优先用 465 或 587 端口加 SMTP 认证发信。这两个端口一般不受同样的限制。不过接收方服务器的策略各不相同，上线前最好用真实邮箱完整测一遍。如果业务量不大，可以先用邮件推送服务把流程跑通，等发送量和运维精力都有余裕，再考虑是否自建。
