2026-10-16 · 上线实录 ③ / ④ · 邮箱

邮箱在收信,
却不让我进门

记录配好了,收信也验证过了。可轮到我自己用这个身份收发时, 服务器一律回:认证失败。

先证明它真的能收信

记录就位之后,我没有急着登录,而是做了一次硬验证:直连对方的收信服务器, 用 SMTP 协议问一句「这个收件人存在吗」。结果是:

hello@dola.cn → 250 Rcpt Ok; 随手编一个同域下不存在的地址 → 554 doesn't exist。

一个真、一个假,这才叫验证通过。如果两个地址都回 250,那说明这台服务器「什么都收」, 这个测试就毫无意义——对照组才是它的价值所在。

(第一次这样测的时候,整台服务器把我们拒了:我们用的发件人域名没过对方的 SPF 校验。 换成空发件人 MAIL FROM:<> 就绕过了这一层。)

然后就卡住了

收信没问题。但当我以 hello@dola.cn 的身份登录收发时,服务器一律回「认证失败」。 于是开始了一轮现在回想有点好笑的排查:

换了几种登录名写法(完整邮箱、只写前缀、账号名)、换了两套认证方式(LOGIN 和 PLAIN)、 把重置密码的思路都铺好了。所有线索都指向「密码不对」。

我甚至一度怀疑是免费版不支持第三方客户端,专门去翻官方文档——文档明确写着支持, 还配了一堆客户端的配置教程。方向又断了。

真相在一个没人看的页面里

最后是翻后台翻出来的。在「访问策略」那一页,安安静静躺着一条谁都没注意的策略:

名称「禁止使用三方客户端」、类型「黑名单策略」、生效对象「所有用户」、 适用客户端「三方客户端」、状态「开启」。

它开着,就意味着任何第三方邮件客户端都进不来——而服务器给出的报错是「认证失败」, 把人稳稳地引向密码那条岔路。

关掉它,再登一次:

[mail] login OK
[mail] inbox: 3 messages
[mail] self-test message sent, waiting 25s for it to arrive...
[mail] inbox now: 4 messages (was 3)

密码从头到尾都是对的。

知识点|认证失败 ≠ 密码错
认证失败只说明「这个组合没通过」。原因可能是密码、可能是策略、可能是 IP 限制。 建议的排查顺序是:先看服务端的策略开关,再怀疑凭据—— 改密码是成本最高、也是最容易白改的那一步。

《上线实录》连载:① 部署通道 · ② 域名解析 · ③ 邮箱 · ④ 方法论 —— 最后一篇收个尾:为什么这一天会被「成功」骗到那么多次。 回到笔记