2026 年微软邮件投递遇阻：排查原因、实现限流，72 小时解决问题

解决向微软用户发送邮件的问题

2026 年 2 月 24 日，收到使用微软邮件服务的用户投诉，称收不到邮件。查看 Sendgrid 日志，发往 Hotmail、Live、MSN 和 Outlook 邮箱地址的邮件被 `延迟`，Sendgrid 给出的延迟原因是 IP 信誉问题致邮件服务器被临时限流。但 Sendgrid 显示发送信誉达 99%，Gmail 邮件管理员工具显示垃圾邮件率正常，且在 SPF、SKIM 和 DMARC 方面遵循最佳实践，近期也未更改邮件设置。在谷歌搜索错误代码，发现不止自己遇到问题，推测是微软故障或配置错误。

问题影响与初步应对

邮件投递可靠性对业务至关重要，每月约发 35 万封邮件，其中约 3.9 万封是事务性邮件，所有邮件通过两个专用 IP 发送，而这两个 IP 都被限流。Helpscout 上投诉不断，指示客户体验（CX）代表创建预设回复安抚用户，Helpscout 发送的邮件不经过 Sendgrid IP。

深入研究与发现

尽管坚信是微软问题，仍深入研究，了解到微软对邮件投递比 Gmail 等更敏感。创建了微软版的 Gmail 邮件管理员工具 [SNDS] 账户，确认 IP 信誉正常，投诉率低于 0.1%，事件前几天无异常，更确信是微软问题。通过微软支持门户发邮件，包含部分 Sendgrid 日志，提交后不乐观能很快得到回复。研究发现发件人可能因发送流量激增被限流，微软这么做是为控制潜在威胁。

数据查询与推测

进行 SQL 查询，过滤掉数量少于 50 的记录后，结果显示 2026 年 2 月 23 日 21:48:00 的数据很可疑，自 2025 年 11 月以来，从未在一分钟内向微软用户发送这么多邮件。收到微软模板回复称发送 IP 没问题，回复说明情况，尽量保持专业。CX 代表处理用户反馈，Sendgrid 会重试延迟邮件，持续 72 小时，封禁时长未知，让人焦虑。

实现限流工具

根据 SQL 查询和邮件投递研究，决定控制向微软用户的发送速率，用 Redis 实现了一个简单的限流工具，并展示了使用方式。

问题解决与后续推测

在部署并监控限流工具时，收到微软工作人员 Anthony 的回复，称针对 IP 的连接和限流限制已调整到更合适的水平。几小时后，Sendgrid 开始正常向 Hotmail、Live、MSN 和 Outlook 邮箱地址投递邮件，整个事件在 72 小时内解决，无邮件被丢弃，部分邮件延迟约 72 小时。实现限流机制后，向微软邮箱地址的发送速率未超每个 IP 每分钟 10 封邮件，用户不在意几秒延迟。

推测原因

由于 `451 错误` 细节少，Anthony 未承认微软故障或更改，推测在时事通讯发送任务中，微软认为两个 IP 发送流量激增，怀疑异常进行了未明确时长的封禁。尽管 2025 年 11 月有类似发送量，但这次可能因微软配置调整更敏感，或“峰值”更明显，其算法更复杂。对公司而言，问题更严重，因通过两个 IP 同时发送事务性和批量邮件，用户多投诉收不到事务性邮件。想为事务性邮件专门用一个 IP 预热，但每月约 3.9 万封事务性邮件量不够，研究表明每月约 10 万封邮件才能保持 IP 热度，回想起来，若能通过共享 IP 发送邮件就好了。最后认为 Sendgrid 很棒，使用近十年很满意，但他们应在 IP 层面负责对发往微软的邮件限流，否则可能导致发送 IP 被微软无限期封禁。