MailPlus 安全日志报 550 5.1.1 User unknown：收件人不存在，改地址还是开 catch-all
痛点场景
客户说"发给你们的邮件被退回了"，你去 MailPlus Server > 审核 > 日志 里查对应时段，看到这么一条：
550 5.1.1: Recipient address rejected: User unknown in local recipient table
翻译过来：有人往你们域名下的某个地址投信，你的 MailPlus Server 在 SMTP 对话阶段就拒绝了——收件地址在你的组织里不存在。
官方诊断
按官方知识库：MailPlus Server 拒绝该 SMTP 连接，是因为您的组织中不存在收件人电子邮件地址。
常见的触发场景：对方把 sales 写成了 sals、离职员工的旧地址还被外部联系人使用、印刷资料上把账号印错。（场景举例为一般归纳，非官方原文。）
处置一：核对地址
官方第一步：检查电子邮件地址是否属于 MailPlus Server > 域中已激活的用户或别名。
- 属于已激活的用户或别名，但信仍被拒——再核对该用户的帐户状态与域名归属，属于另一层排查；
- 不属于——官方结论很直接：电子邮件地址可能有误，请发件人核对地址后重发。
处置二：启用 catch-all 邮箱兜底
如果业务上必须接住这类写错地址的来信——对外印刷资料多、地址暴露面大的公司很常见——官方给出 catch-all 方案：
- 进入 MailPlus Server > 域；
- 选择目标域并单击编辑；
- 单击高级；
- 勾选启用 catch-all 复选框；
- 从下拉菜单中选择一个用户帐户作为 Catch-all 邮箱。
此后发往该域不存在地址的邮件都会落进这个兜底邮箱，由专人定期分拣，不再直接退回。
开 catch-all 前想清楚两件事
- 兜底邮箱接得住写错的信，也会接住大量试探与垃圾邮件——向一个域的常见账号名批量群发是垃圾邮件发送方的惯用手法，开了 catch-all 等于照单全收；（此为一般机制提醒，非官方原文。）
- 记得给兜底邮箱配好分拣与清理规则，否则它很快会成为新的运维负担。
拒收不存在的地址本是邮件服务器的基本功，要不要为写错的信开口子，取决于业务暴露面。诚鑫致达科技开 catch-all 前会先和客户确认对外地址的使用情况——接得有依据，拦得也安心。