微软未公告即拒收未配置DMARC域名发往Outlook的邮件

自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的第一步，p=reject告诉接收方拒收伪造你域名的邮件。 如果你想要一个从第一天起就能正确签名你外发邮件的中继，我们的设置文档涵盖了SPF、DKIM和DMARC，你可以随时开始试用。今天就添加这条记录。只需几分钟，而且它让你的邮件少了一个消失的理由。