微软Outlook.com未公告即拒收无DMARC记录域名的邮件

自2026年11月5日起，微软的消费级邮件服务一直在拒收来自未发布DMARC记录的域名的部分邮件。如果你的公司向使用outlook.com、hotmail.com、live.com或msn.com地址的客户、供应商或申请人发送邮件，其中一些邮件现在可能正在被退回。没有任何公告。解决办法就是一条DNS记录。

发件人会收到这样的退信，后面跟着一个方括号内的服务器名称和ID，每封邮件各不相同： 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) 第一天，同样的拒收信息返回时没有(AS9031519)代码： 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records 这段措辞暗示有什么东西严重损坏了。通常并非如此。我们看到的被退回的域名大多有正常工作的SPF，许多还有DKIM。它们缺少的是将这两者与From地址关联起来的DMARC记录。

微软确实有已发布的发件人规则。自2025年5月起，每天向Outlook.com发送超过5，000封邮件的域名必须通过SPF、DKIM和DMARC，否则会收到550 5.7.515 Access denied。该规则针对的是营销人员和批量发件人，大多数小企业理所当然地认为它不适用于自己。

这次的新拒收在关键方面有所不同： 我们于11月5日首次在自己的出站日志中看到这些退信。来自其他管理员的公开报告也在同一天开始出现。 微软只拒收受影响域名的部分邮件。一封发往Hotmail地址的邮件通过了，下一封被退回，重发可能会成功。这种不一致正是它的危险之处：发送邮件的人看到一封满是缩写的退信，以为是故障，就继续工作了。另一端的客户从不知道曾有一封邮件发出。

如果你的业务依赖于联系使用个人地址的人（患者、房主、申请人、家长、会员），代价是无声的。发票没送到，预约确认从未到达，回复看起来像你无视了某人。

如果你的域名没有DMARC记录，它就是暴露的。你可以在任何终端上用几秒钟检查。将example.com替换为你的域名： dig +short TXT _dmarc.example.com 以“v=DMARC1”开头的行表示你有记录。没有输出表示你没有。这就是本次拒收针对的情况。 p=none是安全的起点。它声明你的域名使用DMARC，并要求接收方给你发送报告，但告诉它们不要对失败采取行动。Gmail、Yahoo或任何其他人如何处理你的邮件都不会改变。

有一个条件。只有当你的From地址中的域名通过SPF或DKIM时，DMARC才会通过。如果两者都不匹配，仅有DMARC记录无济于事。我们在《SPF、DKIM和DMARC不再可选》中介绍了对齐如何工作，以及为什么大多数配置都在这里出错。 分步说明，包括对全部三条记录的检查，在我们的Outlook.com 5.7.1错误指南中。

你通过MailRoute出站中继发送的邮件已经通过了DMARC所需的两项检查： 对于MailRoute发件人，DMARC记录就是全部的修复方案。一旦它就位，Outlook.com看到的是一个通过认证的域名，DMARC在任一检查上都会通过。我们的《为MailRoute出站中继发布DMARC》指南会在你准备好时带你从p=none走向强制执行。

DMARC记录仍然是解决办法，但发送你邮件的服务必须为你的域名通过SPF或DKIM。例如，Microsoft 365在你为自己的域名开启DKIM之前，会用自己的onmicrosoft.com域名签名，而该签名不计入DMARC。我们的姊妹公司mxio有一份针对任何发件人的此错误指南，页面中带有一个测试你域名的检查器。

这是每个主要邮箱提供商都在遵循的模式。要求从批量发件人开始，带着截止日期宣布，然后悄然成为所有人的基线。p=none的DMARC现在是底线，而不是最佳实践。

这不是坏事。欺骗是当今许多网络钓鱼和商业电子邮件入侵的起点，而一个通过认证的域名是一个更难被冒充的域名。今天让你的邮件送达Outlook.com的p=none记录，也是通往p=reject的第一步，后者告诉接收方拒收伪造你域名的邮件。

如果你想要一个从第一天起就能正确签名你出站邮件的中继，我们的设置文档涵盖了SPF、DKIM和DMARC，你可以随时开始试用。今天就添加这条记录。只需几分钟，而且它让你的邮件少了一个消失的理由。