Defaults.Exposed › 修复 › Guides
Outlook 拒收你的邮件：550 5.7.515、550 5.7.509 和 compauth=fail，解读与修复（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
两个不同的微软系统会拒收邮件。消费者版 Outlook.com 会拒收认证失败的大宗发件方（550 5.7.515，自 2025 年 5 月起强制执行）；Exchange Online 则会拒收未通过你自己 DMARC 拒收策略的邮件（550 5.7.509）。根据 Defaults.Exposed 对 261,086,232 个域名的普查，在授权 spf.protection.outlook.com 的 10,205,070 个域名中，85.0% 用了严格 SPF，但只有 21.7% 强制执行 DMARC。
大多数“Outlook 拒收我的邮件”问题其实根本不是拒收——而是邮件悄无声息地落进了垃圾箱，标头里带着 compauth=fail。这篇指南解读微软的各个代码，教你怎么读 Authentication-Results 标头，并按顺序给出修法：确认 SPF、为自定义域名启用 DKIM、发布并强制执行 DMARC、重新测试。
你遇到的到底是哪种微软错误？
微软运行着两套独立的收信系统，拒收的原因也不一样。先对准你的症状——诊断错了会白白浪费一整天。
| 代码/信号 | 来自哪里 | 意味着什么 | 数据截至 2026-06-29 |
|---|---|---|---|
| 550 5.7.515 | 消费者版 Outlook.com / Hotmail / Live | 你每天给消费者版 Outlook 发超过 5000 封邮件，且未达到认证要求（SPF + DKIM + DMARC），自 2025 年 5 月起强制执行 | — |
| 550 5.7.509 | Exchange Online / EOP（企业租户） | 接收服务器执行了你自己域名的 DMARC p=reject 策略——你的邮件未通过 DMARC | 所有 261,086,232 个已评分域名中，只有 10.59% 强制执行 DMARC |
| 550 5.7.511 | Exchange Online / EOP | 你的发信地址或域名在收件组织或微软的禁发名单上 | — |
| S3140 / S3150 | 消费者版 Outlook.com | 你发信的 IP 信誉不佳——是一次拦截，不是认证失败 | — |
标头里的 compauth=fail | 两套系统都可能出现——最常见的情况 | 邮件被接受了，但进了垃圾箱：微软的复合认证判定失败。没有退信，没有 NDR——只是安静地进了垃圾箱 | 在 10,205,070 个使用 M365 发信的域名中，只有 21.7% 强制执行 DMARC |
确切的 NDR 措辞会变化；在引用之前，请对照一封真实退信核实这些字符串。
550 5.7.515 是什么意思？
这是消费者版 Outlook.com/Hotmail 的要求，不是 Microsoft 365 租户的错误。自 2025 年 5 月起，每天向消费者版 Outlook 地址发送超过 5000 封邮件的发件方，必须通过 SPF、通过 DKIM，并发布与 From 域名对齐的 DMARC 记录（至少 p=none）。达不到这个门槛，消费者版 Outlook 会用类似这样的措辞拒收：
550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.
有两件事这不是：它不是 2026 年才有的新规定（如果你的邮件突然开始被拒收，是你的发信量或 DNS 变了，不是规则变了），它也和收件人的 M365 租户设置无关。修法就是下面这套认证阶梯——偶尔某天活动邮件冲上 5000/天，也算数。
550 5.7.509 是什么意思？
这个来自企业租户上的 Exchange Online Protection，意味着你自己的 DMARC 策略正在被执行：
550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.
仔细读一下——这不是微软在故意刁难你。你的域名发布了 p=reject，这封邮件没通过 DMARC，接收方照你的要求做了。如果被拒收的邮件是合法的，说明某个发信来源（一个通讯工具、一个 CRM、一台扫描发邮件设备）没有以对齐的方式完成认证。不要放宽策略；给那个来源配上对齐的 SPF 或 DKIM——见修复 DMARC 和从 p=none 到 p=reject。
为什么 Outlook 是把我的邮件标上 compauth=fail 丢进垃圾箱，而不是直接拒收？
大多数微软送达率方面的困扰根本不会产生退信。邮件被接受、打分、归档到垃圾箱——唯一的证据就是 Authentication-Results 标头。在收件人的邮箱里（或你自己的 outlook.com 测试邮箱），打开这封邮件，选择查看邮件源，找到这一行：
Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001
compauth 是微软的复合认证判定：即便一个域名没有发布 DMARC 记录，微软也会套用隐式的、类似 DMARC 的检查。常见的取值有：
compauth=fail reason=000——邮件未通过显式认证：你的域名 DMARC 策略是 quarantine/reject，且这封邮件没通过。compauth=fail reason=001——邮件未通过隐式认证：你的域名没有发布（或发布得不够充分的）认证记录，这封邮件看起来不像来自你。这是典型的“我们从没配过 DKIM/DMARC”的信号。compauth=fail reason=6xx——隐式认证失败的各种变体；601特指发信域名是你组织自己接受的域名之一（组织内部伪造，自己发给自己）。
结论是：在微软这边，要读标头，不能只看 NDR。同一行里的 spf=、dkim= 和 dmarc= 判定，会准确告诉你该修哪条腿。
怎么修复 Outlook 的拒收和进垃圾箱问题？
- 先运行免费扫描。 它会一次性为你的 SPF、DKIM 和 DMARC 评分，在你动 DNS 之前就显示出哪条腿在失败。
- 确认 SPF——在 Microsoft 365 上通常已经没问题。 标准记录是
v=spf1 include:spf.protection.outlook.com -all，M365 的设置流程会自动帮你配好：在授权 spf.protection.outlook.com 的 10,205,070 个域名中，已有 85.0% 以严格的-all结尾（数据截至 2026-06-29）。有一点要留意：接收方是对照 Return-Path（RFC5321.MailFrom）域名，而不是 From 标头来评估 SPF 的——所以一个通讯工具可以在它自己的退信域名上通过 SPF，却对你的域名毫无帮助。这就是为什么第 3 步和第 4 步更重要。 - 为你的自定义域名启用 DKIM——两条选择器 CNAME。 在你开启自定义域名签名之前，M365 会用一个不对齐的
onmicrosoft.com默认值签名：发布指向你租户密钥的selector1._domainkey和selector2._domainkeyCNAME，然后在 Defender 门户里启用签名。完整操作路径见在 Microsoft 365 上设置 DKIM。如果 DKIM 显示“通过”但 DMARC 仍然失败，你遇到的是默认签名陷阱。 - 发布 DMARC，然后强制执行它。 先从
v=DMARC1; p=none; rua=mailto:...开始收集报告，修复它揭示出的每一个合法来源，再逐步收紧到p=quarantine和p=reject——分阶段路径见修复 DMARC。这一步是大多数微软用户跳过的：使用 M365 发信的域名中只有 21.7% 强制执行 DMARC。 - 通过阅读标头来重新测试。 给一个消费者版 outlook.com 邮箱发信，打开邮件源，确认
spf=pass、dkim=pass、dmarc=pass和compauth=pass。 - 大宗发件方：达到消费者版 Outlook 的门槛。 每天超过 5000 封时，你还需要一个有效、有人监控的 From/reply-to 地址、能用的退订功能，以及干净的名单——认证能解除 5.7.515；投诉率则决定你是否会被 S3140/S3150 拦截 IP。如果你的 IP 已经被拦截，修好 SPF/DKIM/DMARC 不会解除拦截：需要通过微软的发件方支持申请解封，而认证是保证你以后不会再被拦的原因。
为什么这么多 Microsoft 365 域名依然失败？
因为默认设置只替你做了第一步，其余全靠自己。在授权 spf.protection.outlook.com 的 10,205,070 个域名中，85.0% 带有严格 SPF——这是 M365 在设置时替你配好的记录——但根据 Defaults.Exposed 对 261,086,232 个域名的普查，只有 21.7% 强制执行 DMARC。M365 默认给你严格 SPF，然后大多数租户就止步于此——这正是 compauth 被设计出来要抓的那批人（不过仍然领先于全部已评分域名 10.59% 的 DMARC 强制执行率）。完整服务商对比见我们的邮件服务商 SPF 排行榜。
常见问题
550 5.7.515 是 Microsoft 365 的错误吗？ 不是。它来自消费者版 Outlook.com/Hotmail，针对的是每天发信超过 5000 封的发件方，自 2025 年 5 月起强制执行。企业版 Exchange Online 的拒收用的是不同的代码——最常见的是 550 5.7.509（你自己的 DMARC 拒收策略）或 5.7.511（被禁止的发件方）。
我们收到了 550 5.7.509，但那封邮件是合法的——应该放弃 p=reject 吗？
不应该——你的策略拦住了一个未认证的来源，这说明策略在起作用。在标头或 DMARC 报告里找出那个来源，给它配上对齐的 DKIM（或对齐的 SPF）。放宽到 p=none 会给所有人重新打开精准域名伪造的大门。
compauth=fail 是不是意味着有人在伪造我们？
不一定。reason=001 通常意味着你自己的邮件没法证明是你发的——没有对齐的 DKIM，也没有 DMARC。在 10,205,070 个使用 M365 发信的域名中，只有 21.7% 强制执行 DMARC（数据截至 2026-06-29），所以微软会对其余所有人套用隐式检查，未认证的合法邮件同样会被判失败。
我每天发信不到 5000 封——可以不管这个吗？
你能躲过 550 5.7.515，但躲不过垃圾箱：compauth 在任何发信量下都适用。Gmail 也是同一套打法——见 Gmail 550 5.7.26 指南。修法是免费的；真正的门槛是有没有意识到，而不是成本。
把报告发给老板
如果你是在替别人修邮件——客户、老板，或者那家发票总是被拒收的公司——用证据来收尾这份工作。DNS 生效后重新运行免费扫描，把评分报告转发出去。它会用企业负责人能看懂的大白话，展示 SPF、DKIM 和 DMARC 全部变绿——这正是下次网络保险续保或客户安全问卷询问邮件是否已认证时，他们需要的凭证。修好是好事；能证明修好了才是让你拿到报酬、让他们获得保障的关键。
免费检查你的域名
私密、仅域名所有者可见地看看微软是在 SPF、DKIM、DMARC 的哪一条腿上拦住了你。
检查你的域名 → · 修复 DMARC → · DKIM 通过但 DMARC 失败 → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。