Alibaba cloud international server special offer

腾讯云服务器发邮件总进垃圾箱：25 端口封禁与自建邮局的现实

有个客户半夜给我发消息，说腾讯云服务器邮件发送出去的注册验证码和订单通知，几乎全进了客户垃圾箱，白天刚谈成的单子被这事搅黄了。他第一反应是怀疑服务器中了病毒，我却先问他用了哪个端口、域名有没有配 SPF 记录。答案很典型：他直接用了 25 端口，域名解析里只有一条 MX，别的什么都没有。这不是服务器坏了，而是三个问题叠在一起——端口、身份认证、IP 信誉。

这篇把自建邮局这条路上真正卡人的环节讲透：25 端口为什么默认封禁、解封有多难，465 和 587 到底怎么选，SPF/DKIM/DMARC 和反向解析 PTR 该怎么配，以及很多人到最后才想明白的问题——自建邮局到底值不值。

端口这件事：25 默认封禁，465/587 才是出路

先给最直接的结论：在云服务器上，25 端口默认是被封禁的，这不是一家厂商的规定，主流云厂商基本都这样。 原因很简单，25 端口是传统 SMTP 明文投递端口，也是垃圾邮件群发最爱用的通道，云厂商为了控制平台整体 IP 信誉和滥发风险，默认把它关掉。你直接 telnet 目标邮件服务器 25 会发现连不出去，就是这个原因。

那能不能解封？可以申请，但有门槛。通常需要你说明用途、承诺不发垃圾邮件，部分场景还要求提供域名、服务器用途，甚至企业资质，审核通过后才放开。解封后的责任是跟着 IP 走的：一旦这个 IP 被投诉、被列入黑名单，受影响的是你整台机器甚至整段 IP。所以我一般不建议客户把宝押在解封 25 上，尤其是新购的、没有任何邮件信誉积累的 IP。

更现实的做法是用 465 或 587。587 是提交端口（submission），通常配合 STARTTLS 做加密；465 是老式的 SMTPS，直接走 TLS。两者用途相近，区别在于加密起手的时机：587 先明文建连再升级为加密，465 一上来就是加密会话。客户端配置上，很多程序默认端口是 25，你要显式改成 587 并打开 TLS，比如用 openssl s_client -connect smtp.example.com:587 -starttls smtp 去验证握手是否正常。能用 465/587 解决的，就别去折腾 25 端口解封，这是省时间的选择。

这里还有个特别常见的坑：只改端口不改加密方式。端口填了 587 却没启用 STARTTLS，明文发信会被直接拒绝；端口填了 465 却用了 STARTTLS，同样连不上，因为 465 期待的是建连即加密。端口和加密模式必须成对配置，改完先用一个测试账号发一封到自己的 Gmail、QQ 邮箱看落点，别拿真实客户的地址做第一次试验。

SPF、DKIM、DMARC：让收件方相信你的三件套

端口通了只是第一步，邮件能不能进收件箱，取决于收件方愿不愿意信任你。现代邮箱的判定逻辑是三件套加 IP 信誉。

SPF 是一条 TXT 记录，声明“哪些服务器的 IP 有权以我这个域名发信”。它只认域名，不认邮件内容。配置时要精确保罗你实际发信的出口 IP 或授权主机，比如 v=spf1 include:你的服务商 ip4:你的出口IP -all。这里最常见的坑是写成 ~all（软失败）就以为万事大吉，实际上软失败对垃圾邮件判定几乎没有约束力，也挡不住别人伪造你的域名。正确收紧应该用 -all（硬失败），但这要求你把所有合法发信源列全，否则会误伤自己正常发信。

DKIM 是给邮件加数字签名，收件方用你域名下发布的公钥验签，确认邮件在传输途中没被篡改、确实来自你。DKIM 的 selector、私钥要保管好，私钥泄露等于别人能冒充你签名，风险很大。

DMARC 是策略层，告诉收件方“当 SPF 或 DKIM 校验失败时怎么办”，并做域名对齐（alignment）。它还能让你收到聚合报告（RUA），看到有哪些 IP 在冒充你的域名发信。三者关系是：SPF 管发送方授权、DKIM 管完整性与来源、DMARC 管失败策略与反馈。只配 SPF 不配 DMARC，等于装了门锁却没装报警器。

我帮客户排查进垃圾箱时，第一步永远是查这三条记录：用 dig txt 你的域名、dig txt selector._domainkey.你的域名、dig txt _dmarc.你的域名 逐条确认是否生效、语法是否正确。很遗憾，我见过最多的失败原因就是 SPF 语法写错——一条记录里出现两个 v=spf1，或者 include 的服务商已经过期。

反向解析 PTR 与共享 IP 信誉

除了三件套，还有一个经常被忽略的东西：反向解析 PTR。正向解析是域名到 IP，反向解析是 IP 到域名。很多收件服务器会去查你的发信 IP 有没有对应的 PTR 记录，如果没有，或者 PTR 指向的域名和你的 HELO 名对不上，就会被判定为可疑。云服务器默认的 PTR 往往是一串通用主机名，这个在正式发信场景里并不理想，需要在控制台把弹性公网 IP EIP 的反向解析改成你自己域名下的主机名。

比 PTR 更麻烦的是 IP 信誉，尤其是共享 IP 信誉。如果你的服务器用的是和一堆人共用的出口 IP，那么别人滥发垃圾邮件留下的“案底”会一起算在你头上，这就是为什么有些服务器明明配置全对，却依然进垃圾箱——你和“坏邻居”共用了同一个 IP 信誉池。投诉率是硬指标：收件方看的是“这个 IP 收到的用户投诉比例”，一旦越线，整段 IP 可能被降权。自建邮局的隐形成本，很大一部分就在这里。

所以我在给客户做邮件发信规划时，会把三件事分开看：身份认证（SPF/DKIM/DMARC）、IP 身份（PTR 与独立 IP）、流量行为（发送频率与投诉率）。三者有任一短板，都会把另外两项的努力抹掉大半。

自建邮局 vs 企业邮 / 邮件推送：到底该选哪个

聊到这儿，得说一句掏心窝的话：多数中小企业其实不该自建邮局。自建邮局的吸引力是“可控、不回传第三方”，但你要自己维护 IP 信誉、处理被拉黑申诉、监控投诉率、应对反垃圾策略变化，这些是运维负担而不是一次配置就完事的活。收件箱、发件箱、退信、灰名单、限流，每一项都可能是半夜的工单。更现实的是，它本质上是一个需要持续盯着的运维项目，而不是做完一次配置就一劳永逸的技术选型。

相对而言，企业邮箱（比如腾讯企业邮这类托管邮局）负责的是“人用邮箱”场景，域名托管、反垃圾、稳定性都由服务商兜底；而邮件推送 / 邮件 API 服务负责的是“应用发信”场景，也就是程序批量发送的验证码、通知、营销类邮件，它帮你处理投递、退信和信誉。两者的定位完全不同：前者解决员工收发信，后者解决系统发信。

方案 适用场景 主要优点 主要代价

云服务器自建邮局 特殊合规要求 需要完全掌控 数据不外传 可深度定制 要自维 IP 信誉与申诉 运维重

企业邮箱 托管邮局 员工日常收发信 域名托管 反垃圾稳定 不适合程序批量发信 有账号数成本

邮件推送 邮件 API 验证码 通知 营销批量发信 投递率与退信处理由服务商兜底 需按量计费 受服务商规则约束

云服务器只做业务加第三方发信 绝大多数应用系统发信 省心 进箱率高 依赖服务商 敏感数据要看条款

企业邮收信加推送发信 中小团队常见组合 各取所长 成本可控 需维护两套配置与权限

我的实际建议是：把“发信”和“收信”拆开治理。 员工邮箱交给企业邮，程序发信交给邮件推送服务，只有在确有数据不出境或特殊合规要求时，才考虑自建邮局，并且提前按前面说的三件套加 PTR 做完认证。这样既保住投递率，又不用把一台云服务器变成半个邮件运维岗。

顺带提一句边界：无论自建还是托管，发信内容都必须合规，用于营销时要提供退订入口、尊重收件人意愿。任何号称“包进收件箱”“包过垃圾邮件过滤”的渠道，本质是灰产打法，短期有效、长期必然反噬 IP 与域名信誉，我不建议碰。

发信行为与内容：配置对了为什么还是进垃圾箱

认证全绿、端口也对，邮件仍然进垃圾箱，这时要怀疑发送行为和内容本身。最典型的是发送频率突变：一个平时每天只发几十封的域名，突然在半小时内群发上万封，反垃圾系统会直接把它当成被劫持的账号处理，先拦后问。我的经验是新域名、新 IP 要“养”——从小批量、真实收件人、稳定节奏开始，冷启动期不要一上来就群发，这对国际腾讯云服务器还是别的云都一样。

内容层面同样有雷区。正文里堆大量短链接、图片多文字少、标题全大写，都会拉低评分；营销邮件缺少退订入口（比如缺少 List-Unsubscribe 头）也容易被判定为垃圾邮件。还要盯退信率：如果地址列表里存在大量无效地址，硬退（hard bounce）比例高，收件方会认为你在“猜地址”群发，域名信誉掉得很快。所以发送前先做地址有效性校验，发送后监控退信和投诉，比事后写申诉邮件有效得多。

说句实在的，我见过太多团队把精力全花在调 SMTP 参数上，却从不看自己的退信报告和发送曲线。进箱率是个系统工程，端口、认证、IP 信誉、发送行为四块，缺一块都可能前功尽弃。把监控做起来——每周看一次退信率、投诉率和各收件域的落点——比临时抱佛脚强得多。

FAQ

Q：腾讯云服务器 25 端口能解封吗？

A：可以申请，但需说明用途并承诺不滥发，部分场景还要资质审核。即便解封，责任跟着 IP 走，被投诉会波及整台机器，所以更推荐用 465/587。

Q：465 和 587 该选哪个？

A：两者都加密。587 是标准提交端口，先建连再 STARTTLS 升级；465 一上来就是隐式 TLS。新代码优先 587，兼容老客户端可用 465，用 openssl s_client 验证握手即可。

Q：SPF 配了还是进垃圾箱，问题在哪？

A：先查 SPF 语法是否只保留一条 v=spf1、include 是否有效；再检查 DKIM 私钥与 selector 是否匹配；最后看 PTR 和共享 IP 信誉，三件套齐全但 IP 有案底，照样进垃圾箱。

Q：自建邮局能保证进收件箱吗？

A：不能打包票。进箱率取决于认证记录、IP 信誉、发送行为三重因素，自建只是把控制权交给你，也意味着运维和申诉责任全在你身上。

Q：企业邮箱能代替邮件推送服务吗？

A：定位不同。企业邮箱解决员工收发信，邮件推送解决程序批量发信。拿企业邮去群发验证码或营销邮件，很容易触发限流和信誉惩罚。

结语

如果你正在被“邮件进垃圾箱”困扰，按这个顺序排查：先确认端口用的不是 25 而是 587/465；再逐条核对 SPF、DKIM、DMARC 是否生效且语法正确；然后检查 EIP 的 PTR 与是不是共享 IP；最后评估发送行为是否高频、有无退订入口。做业务发信的团队，我的具体建议是尽快把程序发信迁到邮件推送类服务，把自建邮局留给确有需要的场景。拿不准的，把发信域名、端口和 dig 出来的三条记录交给熟悉腾讯云账户开通与排障的服务商看一眼，比自己在垃圾箱里反复试错快得多。

如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。