如何解决遗留系统与第三方系统向Office 365用户发送邮件的投递问题？

兄弟，我太懂你这种头疼了！最近两年Office 365的反垃圾规则确实越收越紧，加上2023年Basic Auth一刀切禁用，好多内部遗留系统、第三方工具发的邮件要么被扔进垃圾文件夹，要么直接被“黑盒”过滤器拦截消失，简直是运维的噩梦——而且这种问题还经常隐藏着风险，比如重要的告警邮件没收到，搞不好要出大麻烦。

我接触过不少同行，大家其实都在想办法解决，只是很少拿到台面上说，给你分享几个实用的方案：

• 用Office 365中继连接器绕开认证要求
  这是最省心的方案之一，完全不用改遗留系统的代码或配置。你可以登录Office 365管理中心，在「邮件流」里创建一个专用中继连接器，把你的内部服务器/遗留系统的固定IP地址加到允许列表里。这样这些系统发邮件时，直接通过这个中继投递到Office 365，不需要任何OAuth或账号认证，还能绕过大部分反垃圾检查。注意一定要把允许的IP严格限制在内部网络，别对外开放，防止被滥用。

• 搭建内部SMTP中继服务器做中转
  如果你的遗留系统连SMTP服务器地址都没法改，或者不想直接在Office 365里开IP白名单，可以自己搭一台中继服务器（比如Windows IIS SMTP、Linux的Postfix）。让所有遗留系统先把邮件发到这台中继上，再由中继服务器统一用OAuth认证对接Office 365。所有复杂的OAuth配置都集中在中继上，遗留系统完全不用动——我之前给公司的老ERP系统就这么弄的，省了好多事。

• 给特定系统创建Office 365反垃圾例外规则
  要是碰到那种真的完全没法改造的古董系统，试试在Office 365的反垃圾邮件策略里加例外：比如把系统的发件邮箱、发件IP，甚至邮件里的特定关键词（比如告警标题）加入白名单，确保这类邮件不会被拦截。不过这个方法要谨慎，别开太大的口子，不然容易给垃圾邮件留空子。实在不行也可以联系微软支持，说明你的特殊场景，看看能不能申请放宽限制，虽然不一定每次都成，但值得一试。

• 长期方案：逐步替换或改造遗留系统
  上面的方法都是临时救急，从长远来看，还是得慢慢处理那些无法支持现代认证的系统。比如找第三方开发商要支持OAuth的更新包，或者用脚本写个中间层，把系统生成的邮件转换成符合OAuth要求的格式再发送。实在不行，就考虑替换成支持Office 365现代认证的新系统——毕竟依赖古董系统迟早会出更大的问题。

至于你说为啥很少听到这个话题？其实不是大家忽略，是很多公司都在私下解决，要么用上面这些方法绕过去了，要么小公司没碰到大规模的问题，还有的就是运维团队默默搞定了没声张。你绝对不是一个人在面对这个麻烦！

备注：内容来源于stack exchange，提问作者Rop