Outlook静默拒收无DMARC域名邮件

自2026年11月5日起，微软（Microsoft）的消费者邮件服务开始拒收部分来自未发布 DMARC（Domain-based Message Authentication, Reporting, and Conformance）记录的域名的电子邮件。

如果您的公司使用 outlook.com、hotmail.com、live.com 或 msn.com 地址向客户、供应商或求职者发送电子邮件，其中部分邮件现在可能会被退回。没有任何官方公告。解决方法只需一条 DNS（Domain Name System）记录。

核心要点

· Outlook.com、Hotmail、Live 和 MSN 现在会拒绝一部分来自没有 DMARC 记录的域名的邮件。

· 受到冲击的是普通、低发信量的发送者，而不仅仅是微软已公布规则所涵盖的大宗邮件发送者。

· 只有部分邮件被退回，因此“我的邮件能发出去”并不意味着您的域名是安全的。

· 解决方法是一条单一的 TXT 记录：v=DMARC1; p=none，这不会改变其他接收方处理您邮件的方式。

退信的外观

发送者会收到类似这样的退信，随后是每条邮件各不相同的括号内的服务器名称和 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（Sender Policy Framework），许多域名也配置了 DKIM（DomainKeys Identified Mail）。它们缺失的是将这两者与 From 地址绑定在一起的 DMARC 记录。

改变了什么

微软确实有公开的发信规则。自2025年5月起，每天向 Outlook.com 发送超过 5,000 封邮件的域名必须通过 SPF、DKIM 和 DMARC 验证，否则将收到 5.7.515 Access denied 错误。该规则针对的是营销人员和大宗邮件发送者，大多数小型企业理所当然地认为这与他们无关。

这种新的拒收在关键方面有所不同：

· 它波及小型发信者。来自小型办公室的一行简短回复也可能会被退回。

· 它没有事先宣布。截至11月6日，微软尚未就此发布任何内容：没有邮管员通知（postmaster notice）、没有博客文章、没有服务健康状态条目。

· 它没有说明哪里失败了。5.7.515 退信会列出 SPF、DKIM 和 DMARC 的结果。而这一条只说缺少记录。

我们在11月5日自身的出站日志中首次看到了这些退信。来自其他管理员的公开报告在同一天开始出现。

为什么它很容易被忽视

微软仅拒收受影响域名的一部分邮件。发往 Hotmail 地址的一条消息通过了，下一条被退回，而重新发送可能会成功。这种不一致性正是该问题危险的原因：发送消息的人看到一封充满缩略图和专业术语的退信，以为是小故障便置之不理。而另一端的客户永远不会知道曾有消息发送过。

如果您的业务依赖于触达个人地址的用户（患者、房主、求职者、家长、会员），那么这种代价是悄无声息的。未送达的发票、从未到达的预约确认函、看起来像是您故意忽视某人的回复。

您的域名受到影响了吗？

如果你的域名没有 DMARC（Domain-based Message Authentication, Reporting, and Conformance）记录，它就是暴露的。你可以从任何终端在几秒钟内进行检查。将 example.com 替换为你的域名：

dig +short TXT _dmarc.example.com

以 "v=DMARC1" 开头的行意味着你有一条记录。没有输出则说明没有。这就是本次拒信所针对的情况。

解决方法只有一条 DNS 记录

在你的 DNS 主机添加一条 TXT 记录：

· 名称：_dmarc

· 值：v=DMARC1; p=none

p=none 是安全的起点。它声明你的域名使用 DMARC 并请求接收方为你发送报告，但它告诉接收方对验证失败不采取任何操作。Gmail、Yahoo 或其他任何人处理你邮件的方式都不会发生改变。

有一个条件。只有当 From 地址中的域名通过了 SPF（Sender Policy Framework）或 DKIM（DomainKeys Identified Mail）验证时，DMARC 才会通过。

如果两者都未对齐，仅靠 DMARC 记录是无济于事的我们在《SPF、DKIM 和 DMARC 不再是可选项》（SPF, DKIM, and DMARC Are No Longer Optional）一文中探讨过对齐的工作原理，以及为什么它是大多数配置出错的环节。

包含所有三条记录检查在内的分步说明，位于我们关于 Outlook.com 5.7.1 错误（Outlook.com 5.7.1 error）的指南中。

如果你的邮件通过 MailRoute 发送

你通过 MailRoute 出站中继发送的邮件已经通过了 DMARC 所需的两项检查：

· SPF。你的邮件将你自己的域名保留为信封发件人（envelope sender），并从包含 include:spf.mailroute.net 授权的服务器发出。

· DKIM。我们使用你的 mr01、mr02 和 mr03 CNAME 记录指向的密钥，将每封出站邮件签名为你的域名。请发布所有这三条记录，以便我们能够在不中断你的签名的情况下轮换密钥。

对于 MailRoute 发件人来说，DMARC 记录就是全部的解决方法。一旦配置完成，Outlook.com 就会识别到一个通过身份验证的域名，并且 DMARC 会在任一检查中通过。

我们的《为 MailRoute 出站中继发布 DMARC 指南》（guide to publishing DMARC for the MailRoute outbound relay）将带你在准备就绪时从 p=none 过渡到强制执行（enforcement）。

如果你的邮件不通过 MailRoute 发送

DMARC 记录仍然是解决方法，但发送你邮件的服务必须为你的域名通过 SPF 或 DKIM 验证。例如，Microsoft 365 默认会使用其自己的 onmicrosoft.com 域名进行签名，直到你为自己的域名开启 DKIM，而该签名对 DMARC 是无效的。

我们的姊妹公司 mxio 针对所有发件人提供了此错误的指南，页面上还带有用于测试你域名的检查工具。

发展趋势

这是每个主要邮箱提供商都在遵循的模式。要求从群发邮件发送者开始，通过设定最后期限进行公告，然后静悄悄地成为所有人的基准。p=none 级别的 DMARC 现在是底线，而不是最佳实践。

这不是一件坏事。电子邮件欺诈（Spoofing）是当今许多网络钓鱼和商业电子邮件诈骗（Business Email Compromise）的开端，而经过身份验证的域名要比难以被冒充。今天能让你的邮件顺利投递到 Outlook.com 的 p=none 记录，也是迈向 p=reject 的第一步，后者会指示接收方拒收伪造你域名的邮件。

如果您希望拥有一个从第一天起就能正确为您的外发邮件进行签名的中继服务，我们的设置文档将指导您完成 SPF、DKIM 和 DMARC 的配置，并且您随时可以开始试用。今天就添加记录吧。只需几分钟，就能让您的邮件少一个消失的理由。