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 限制。 建议的排查顺序是:先看服务端的策略开关,再怀疑凭据—— 改密码是成本最高、也是最容易白改的那一步。
《上线实录》连载:① 部署通道 · ② 域名解析 · ③ 邮箱 · ④ 方法论 —— 最后一篇收个尾:为什么这一天会被「成功」骗到那么多次。 回到笔记