微软误拦合法邮件：一次误伤，暴露了DMARC的真实门槛

微软本用于拦截恶意邮件的过滤器，在11月5日到9日之间意外拒绝了一批合法邮件。受影响的是发往Outlook.com、Hotmail、Live和MSN等微软免费邮箱的邮件，退信理由是缺少DMARC记录或认证失败。微软没有提前发布策略变更公告，也没有postmaster通知或服务健康预警，很多企业是收到退信后才察觉问题。

微软自2025年5月起规定：向微软免费邮箱日发送量超过5000封的域名，必须配置DMARC。但这次被退回的邮件，很多并非批量发件人发出，而是来自小规模发件人。未送达报告给出的错误代码为550 5.7.1或550 5.7.23，情况却不一致：同一域名发出的邮件，一部分正常送达，另一部分直接被拒。

微软社区论坛上有用户贴出退信：“您发送至@hotmail.com的邮件无法送达。hotmail.com无法确认您的邮件是从受信任的位置发出的。”更让人困惑的是，一些被退回邮件所属的域名，经查SPF、DKIM和DMARC均配置正常。微软社区的一位外部版主当时称正在调查；微软官方最终的定性是反垃圾规则更新导致的误判，不是主动限制服务。

邮件安全公司MailRoute给出了一个简单自查方法：在终端运行

text

dig +short TXT _dmarc.example.com

把域名换成自己的。返回结果以v=DMARC1开头，说明有DMARC记录；什么都没返回，就是没有。最基础的修复是一条TXT记录：

text

v=DMARC1; p=none

这条记录声明该域名使用DMARC、要求接收方发送报告，但在验证失败时先不要求接收方拦截或隔离。

DMARC依赖两个基础认证：SPF校验发送服务器IP是否被允许代表某个域名发信；DKIM给邮件加加密签名，证明邮件未被篡改、确实属于它声称的域名。DMARC检查两者，确认“发件人”地址中的域名与已验证域名是否一致，并告诉接收方如何处理伪造邮件。没有它，冒充一个域名轻而易举，大量钓鱼和商业邮件欺诈正是从这里开始的。

问题在于，微软目前只对批量发件人强制要求 DMARC，很多小规模发件人因此认为这不适用于自己——中小企业、非营利组织、学校，以及律所、会计师事务所、医生诊所等专业机构。它们的域名往往多年前搭建完成后就没人再动过。规模较大的企业则容易在辅助域名、地区性域名，以及营销和账单平台发信所用的子域名上遗漏 DMARC。DNS没有明确归属者，人们也害怕改错会破坏第三方发送的合法邮件。

这次故障危险的地方在于它的不一致：发件人看到退信满篇缩写，以为是小故障就继续做别的事了。而收件的那一端，客户、患者、候选人根本不知道有邮件被发出过。发票、密码重置、预约确认和录用通知没有送达时，对方只会觉得自己被忽视了，未必意识到是邮件没有到。

还有一个操作风险：故障期间被拒绝的邮件，微软不会自动补发。

系统修复的是后续投递通道，不会恢复已经退回的邮件。如果你在11月5日到9日之间曾向Outlook/Hotmail发送过重要事务邮件，建议检索邮件日志、退信报告和服务台工单，查找标注“缺少SPF/DKIM/DMARC”的条目，必要时手动重发。

排查之后，确认每一个以你的名义发信的域名都发布了DMARC记录。如果某个域名缺少记录，一条p=none的监控记录就能阻止这些退信，同时不会改变其他人对你邮件的处理方式——前提是SPF或DKIM与“发件人”域名对齐。从未为自己的域名启用DKIM的Microsoft 365客户应尽快开启。不要仅仅因为退信归咎于SPF就去重写SPF。如果确认全部认证记录配置无误，但邮件依旧持续被退回，请收集完整原始退信提交给微软技术支持，协助调查。

但p=none只是起点，不是终点。目标是p=reject，告诉接收方拒绝任何冒充你域名的邮件。升级之前有一个前提：盘清每一个以你的名义发送邮件的服务——CRM、账单系统、HR平台以及营销工具。大多数组织拿不出这份清单。当你不知道谁在代表你的域名发言时，你就无法保护这个域名。

配置完DMARC之后，新的难题是报告看不完。Gmail、Outlook、Yahoo等主流服务商会每天推送XML格式的DMARC聚合报告，记录有哪些IP在代表你的域名发信、认证过没过、失败原因是什么。域名一多、时间一长，人工翻XML基本无法持续。

如果企业希望持续查看这些报告，市面上有对应的DMARC报告解析与监控工具，例如靠谱DMARC邮件认证监控平台。这类工具的功能范围通常包括：自动接收并解析各大服务商发来的XML聚合报告，整理为可视化看板，展示发信来源、SPF/DKIM/DMARC认证通过率和异常摘要；支持多域名和子域名集中管理；在出现认证失败、陌生IP发信或疑似仿冒时，通过企业微信、钉钉或邮件发出告警。需要说明的是，这类工具不修改DNS记录，也不对“配置后邮件是否进入垃圾箱”作出保证；其作用范围限于让DMARC报告的解析和查看更持续、更可回溯，包括回溯类似这次故障中那些无声发生的退信。

虽然这次故障的成因是规则更新误判，但方向不应看错：DMARC要求会逐步覆盖越来越多的发件人。谷歌和雅虎于2024年2月开始对批量发件人提出要求，微软于2025年5月跟进。2026年，海外主流邮箱服务商持续收紧邮件身份认证门槛。Gmail已经对日均超过5000封的批量发件人在SMTP层面直接拒收不合规邮件；小规模发件人不在强制拒收范围内，但认证缺失带来的风控权重上升，同样会影响投递稳定性。DMARC已经从“建议配置项”演变为跨境发信的基础准入条件。

2026年5月，IETF发布RFC 9989，将DMARC从Informational文档升格为Standards Track标准，正式取代2015年的RFC 7489。协议层面的方向已经明确，执行节奏仍由各邮箱服务商自行决定。这意味着DMARC不再只是一项可选的行业实践，而是邮件身份认证的标准机制。

要求总是从批量发件人开始，然后成为所有人的底线。这次推行出了问题，但方向没有变。只是，任何人都不应该直到收到一封退信，才第一次得知一条新规则。

11月10日，微软发表声明称，该问题（与其垃圾邮件规则更新有关）已经解决。普通发件方无需调整DNS设置或采取额外操作。微软发言人表示：“我们已经解决了一个可能导致部分邮件无法送达Outlook.com、Hotmail 和 Live地址的问题，邮件流已恢复。我们将继续监控，以帮助确保邮件按预期送达。”客户可通过Microsoft 365管理中心EX1545193了解更多信息。

通道修好了，已经退回的邮件不会自己回来。对大多数企业来说，先补上那条p=none，再把DMARC报告持续看住，比等下一次退信出现在客户那里再翻日志，要踏实得多。