最近几天，由于邮件认证缺失或验证失败，发往Outlook、Hotmail等微软消费者邮箱账户的正常邮件出现被退回的情况，这种不稳定的过滤现象，无论是源于程序漏洞还是政策变更，都给用户带来了困扰。
微软原本用于保护用户免受恶意邮件侵害的邮件过滤系统，似乎开始拦截正常的合法邮件。
过去几天内，一些发往微软消费者邮箱地址（包括Outlook、Hotmail、Live和MSN）的邮件，由于未发布基于域名的消息认证、报告和一致性（DMARC）记录而遭到退回。这一拒收问题从11月5日开始出现，截至发稿时仍在持续。微软方面并未宣布任何政策变更，也未发布邮局管理员通知、服务健康状态说明或相关博客文章。
迪克森研究公司的弗兰克·迪克森指出，这一问题可能同时涉及政策变更和程序漏洞两方面因素。
他表示："要求每个发送域证明自己的真实身份，这本身能让邮件系统更加安全。但在没有事先通知的情况下推行这一要求，而且错误提示信息还指向错误的问题所在，就会造成混乱。"
间歇性发送问题
DMARC机制旨在防范域名伪造、网络钓鱼和商业邮件欺诈等问题。微软自2025年5月起就已实施DMARC规则，但该规则仅适用于每日向消费者邮箱发送超过5000条消息的域名。
然而从11月5日起，一些普通的小型发送方（而非批量发送方）发出的邮件，也因缺乏DMARC、发件人策略框架（SPF）或域名密钥识别邮件（DKIM）认证而被退回。发送方收到的退信通知（NDR）中标注了550 5.7.1或550 5.7.23错误代码，但这种退信情况并不稳定；部分邮件能够成功送达，另一些则遭到拒收。
例如，一位用户在微软社区论坛上报告了如下错误信息：
您发往<已隐去>@hotmail.com的邮件无法送达。
hotmail.com无法确认您的邮件是从可信位置发送的。
另一位用户也报告了同样的问题，并补充说："有些邮件能正常发送，另一些则返回SPF验证失败的错误。"更令人困惑的是，有报告显示，部分被拒收的域名实际上已正确配置了SPF、DKIM和DMARC记录。
一位微软外部员工版主将此称为正在进行积极调查的"服务降级"问题。
据邮件安全公司MailRoute介绍，企业可以在任意终端中执行以下命令（将example.com替换为自己的域名），以判断自身域名是否受到影响：dig +short TXT _dmarc.example.com。如果返回结果以v=DMARC1开头，说明存在DMARC记录；如果没有任何回复，则说明不存在该记录，MailRoute解释道。
解决方案很简单，只需添加一条TXT记录：v=DMARC1; p=none。MailRoute解释说，这表示该域名已启用DMARC机制并要求接收方发送报告，但同时指示接收方对验证失败的邮件不采取任何限制措施。
DMARC旨在防止身份冒充
DMARC机制依赖于两项必须在域名上启用的基础邮件认证工具：SPF和DKIM。
SPF用于验证发送服务器的IP地址是否获得授权代表该域名发送邮件，而DKIM则为邮件添加加密签名，以证明邮件在传输过程中未被篡改，且确实来自其声称的域名。
DMARC对这两项机制进行检查，判断"发件人"地址中列出的域名是否与已验证的域名保持一致。迪克森解释说，这项机制将这些验证与读者实际看到的名称关联起来，并告知接收方该如何处理伪造邮件。
他说："没有DMARC，冒充你的域名就会变得很容易，而这正是许多网络钓鱼和商业邮件欺诈事件的起点。"
但由于微软目前仅对大型发送方强制要求DMARC，这项机制尚未在所有发送方中普及；许多小型发送方据此合理地认为该规则并不适用于自己，迪克森指出。这其中包括中小企业、非营利组织、学校，以及律师事务所、会计师事务所、诊所等专业机构，它们使用的域名往往是"多年前有人设置好之后，就再也没有人维护过"。
即便是大型机构，也常常在次要域名、区域域名，以及营销和账单平台所使用的子域名上疏于配置DMARC，原因往往十分普通。由于域名系统（DNS）没有统一的管理方，"人们担心此举会影响到第三方发送的正常邮件"，迪克森说。
静默且不稳定的失败
正如MailRoute所指出的，这一故障之所以特别危险，就在于它的不稳定性：发件人看到退信通知后，"面对满是专业术语的提示信息，往往会以为是系统临时故障，然后就不再理会了"。而与此同时，收件方根本不知道曾有邮件发出。
这种故障是悄无声息发生的，迪克森称这"正是邮件营销人员最头疼的问题"。客户、患者、求职者等群体普遍使用Hotmail、Outlook、Live和MSN邮箱，当发票、密码重置邮件、预约确认函、录用通知等邮件未能送达时，客户往往会认为自己被忽视了，而不会想到可能是邮件系统出了问题。
好消息是，这些故障是可以被发现的，他指出。每一次拒收都会生成一条退信记录，而这些记录都会被系统记录下来。企业应当检索自11月5日以来的邮件日志、邮件平台的退信报告以及客服工单中标注"邮件缺少SPF/DKIM/DMARC"的相关条目。
随后，应优先重新发送那些重要且具有时间敏感性的交易类邮件。
在此基础上，再着手解决根本原因：确认所有以你的名义发送邮件的域名都已发布DMARC记录，迪克森建议道。如果某个域名缺少该记录，设置一条基础的监测型记录（p=none）即可阻止此类退信问题的发生，而不会改变其他人对你邮件的处理方式，前提是SPF或DKIM与发件域名保持一致。
那些尚未为自己的域名启用DKIM的微软365用户，现在就应该立即启用，他建议道。"不要因为退信提示指责SPF问题就去重写SPF记录，"他说，"如果你的记录本身是正常的，但邮件仍然遭到退回，就应该把完整的退信信息提交给微软，纳入其调查范围。"
不过，设置p=none记录只是"万里长征的第一步，而非终点"，他说。最终目标应该是达到p=reject级别，这意味着告知接收方拒绝任何冒用你名义的邮件。
迪克森建议，企业应当盘点所有以自己名义发送邮件的服务，包括CRM系统、账单系统、人力资源平台以及营销工具。"大多数机构都无法列出这样一份完整清单，"他指出，"如果你不知道谁在代表你的域名发声，就无法真正保护好这个域名。"
未来趋势的信号
尽管这一故障的具体原因目前仍有待查明，但迪克森表示，企业不应对未来的发展方向产生误判：DMARC机制终将对所有发送方强制实施。谷歌和雅虎早在2024年2月就已开始对批量发送方提出这一要求；微软则在2025年5月跟进。
他说："这类要求往往先从大型发送方开始实施，随后逐渐成为所有发送方必须达到的基本门槛。这次推行过程确实存在失误，但最终的发展方向是毋庸置疑的。"不过，尽管微软把握住了正确的方向，"任何人都不应该是通过一条退信通知，才第一次了解到新规则的存在"。
11月10日更新：周二，微软发布声明称，与垃圾邮件规则更新相关的此问题已得到解决。用户无需调整任何设置或采取其他操作。
微软发言人表示："我们已解决了一个可能导致部分邮件无法送达Outlook.com、Hotmail和Live邮箱地址的问题，邮件收发功能已恢复正常。我们将持续监测，以确保邮件能够按预期送达。客户可以通过微软365管理中心的EX1545193编号了解更多详情。"
