一、事件：11 月 5 日起，发往微软邮箱的邮件被”无痕拒收”

据科技媒体 Windows Latest 报道，从 11 月 5 日起，发往 Outlook.com、Hotmail、Live.com 等微软消费者邮箱的邮件出现大规模被拒收的情况，截至 11 月 8 日仍可复现。退信提示统一指向”邮件未通过身份验证检查”，常见错误代码包括：

• 550 5.7.23 —— 提示发件人联系 IT 管理员检查 SPF 配置
• 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) —— 提示邮件”缺少” SPF/DKIM/DMARC 认证记录
• 550 5.7.515 Access denied, sending domain does not meet the required authentication level —— 发件域名未达到微软要求的认证等级

最让人头疼的是这次故障的三个特征：

1. 配置正确的域名也被误拦。 多名用户确认自己的 SPF、DKIM、DMARC 记录完全有效，邮件照样被退——问题出在微软接收侧的路由和验证逻辑，不是发件方配错。
2. “同信不同命”。 同一封邮件发给 Gmail 正常送达，发给 Hotmail 就被退回；有的邮件隔几分钟重发一次就成功了。这说明拦截是随机性的误判，与发件方无关。
3. “无痕”最危险。 收件方完全不知道自己漏了邮件，发件方如果只看”已发送”也发现不了，直到客户问你”怎么一直没收到”。

波及范围不只微软自家用户——Zoho、独立 Exchange、各类企业邮箱发往 Outlook.com 的邮件同样中招。截至目前微软官方没有公开说明，也没有统一解决方案。

二、不是巧合：微软同期全面收紧邮件认证要求

在故障之外，微软确实在推进一项确定性更强的新规（官方技术社区与帮助文档已明确）：对向微软消费者邮箱（Outlook.com/Hotmail 等）单日发送达到 5,000 封的”海量发件人”域名，强制要求：

1. SPF 和 DKIM 必须配置且检查通过；
2. 必须发布 DMARC 记录（DNS 中的 _dmarc TXT 记录，例如 v=DMARC1; p=none）；
3. SPF 或 DKIM 至少一项必须与发件人显示域名（From 域）对齐。

不满足的，邮件会被直接拒收（即上面提到的 550 5.7.515）。换句话说，就算这波故障明天结束，“SPF/DKIM/DMARC 三件套配齐”也已经从加分项变成了微软方向的硬门槛。Gmail、Yahoo、QQ 企业邮等主流服务商近几年都在走同样的路线——邮件认证配齐，是所有企业域名接下来一两年的必答题。

三、企业自查 3 步（今天就能做）

第 1 步：先拿到完整退信代码。 让发件同事把退信原文（NDR）发过来，看错误码是 550 5.7.23 / 5.7.1 / 5.7.515 还是别的。这波微软故障的特征是”配置正确仍被退、重发能成功”，先对照判断是对方故障还是自身问题，不要上来就改 DNS。

第 2 步：核验域名三条认证记录。 在域名 DNS 后台检查：

微软官方建议的稳妥路线是：先 p=none 监控一段时间，确认合法流量无误伤，再逐步升到 p=quarantine / p=reject，不要一步到位设 reject。

第 3 步：做一轮跨平台送达测试。 向 Gmail、Outlook/Hotmail、QQ 邮箱各发一封测试邮件，确认是否送达、是否进垃圾箱；对 Outlook 方向的偶发退信，先重发并保留退信原文，等微软侧修复。

四、我们能帮你做什么

厦门源讯为企业客户提供免费的企业邮箱域名认证记录巡检：帮您核对 SPF/DKIM/DMARC 三条记录是否齐全、语法是否正确、发信来源是否全覆盖，并出具一页式检查结论。无论贵司使用 263、网易 163、阿里云还是腾讯企业邮箱，这套认证标准完全一致，巡检内容通用。

近期如果贵司出现以下任一情况，建议尽快联系我们：

• 发往海外/微软邮箱的客户邮件出现退信或长期无回复；
• 域名从未配置过 SPF/DKIM/DMARC；
• 使用 CRM 或群发平台代发邮件，不确定发信来源是否纳入 SPF。

厦门源讯信息技术有限公司 ｜ 服务电话：0592-5509005