# Outlook.com 退回缺少 DMARC 的小公司邮件，MailRoute 称回一句邮件也可能中招

**Summary:** MailRoute 报告称，Outlook.com 会退回来没有 DMARC 记录的域名发出的邮件，小公司日常的回信也会中招。文章给出该对照的错误码和排查顺序，并提醒先确认适用的策略、认证是否对齐——光加一条 DNS 记录，保证不了送达。

- Canonical: https://markhuang.ai/zh/news/outlook-small-senders-missing-dmarc
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-11-08
- Section: News
- Tags: Outlook.com, DMARC, 邮件送达率, 邮件认证, DNS
- Source: [MailRoute](https://mailroute.net/blog/outlook-rejecting-email-without-dmarc)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一只米色纸质信封停在蓝色投信口前，旁边是一个红色退回箭头](https://cdn.markhuang.ai/news/outlook-small-senders-missing-dmarc/hero.webp)

*概念示意图，由 OpenAI gpt-image-2 生成：一封普通邮件到了收件方，也得先过一道认证关。*

小公司回一句“收到”，到了 Outlook.com 那头也可能被退回，哪怕这个域名早就配了邮件认证。这来自 [MailRoute 11 月 6 日的报告](https://mailroute.net/blog/outlook-rejecting-email-without-dmarc)：公司称从 2026 年 11 月 5 日起开始看到退信，牵涉的域名都没有 DMARC 记录。出问题的是发往微软消费级邮箱的邮件，包括 Hotmail、Live、MSN 和 Outlook.com，而且时好时坏。

真正值得注意的是，微软公开的认证要求只针对每天发信超过 5,000 封的域名。MailRoute 却说，普通的回信也没躲过去。以前觉得“群发规则跟我没关系”的小机构，现在有了具体理由去查自己的域名和退信。

报告还给域名所有者留了一个能照着找的错误码。如果邮件本身已经以收件人看到的 From 地址所属域名通过了认证，发布 DMARC 有可能让这类退信消失。但报告没有证明微软正在对所有域名统一推行，而且一条 DNS 记录也保证不了送达。

## 这和群发新规的退信不是一回事

MailRoute 复现的退信是这样的：

```text
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
```

公司说，不少受影响域名本来就有正常工作的 SPF，有些还配了 DKIM。这两项都是在帮收件方判断这封邮件从哪儿来。MailRoute 把这些故障归到缺少 DMARC 上——DMARC 做的事，是把这些检查结果和人眼看到的发件人地址对上。

[微软关于高发送量发件人的公告](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)描述的是另一种错误：`550 5.7.515`，执行日期为 2025 年 5 月 5 日。具体要求是 SPF 和 DKIM 都得通过，DMARC 策略至少为 `p=none`，并靠其中任意一种认证方式完成对齐。公告的常见问题里说，执行初期针对的是大型发送方。

MailRoute 说，11 月这波退信之前没有任何公告。微软那份指引里，也找不到把范围扩到所有小发送方的说法。现在确实值得查一查自己的投递失败，但这次变动到底波及多广，报告没有答案。

## DMARC 管的是“谁通过了认证”

SPF 查的是：这封邮件的信封发件人域名（envelope-sender）有没有授权这台服务器替它发信。这个地址只在投递过程中使用，收件人看不到。DKIM 查的则是一段数字签名，看它跟哪个签名域名绑定。可无论哪一项通过，都不等于收件人看到的那个域名就通过了认证。

有些邮件服务用自己的域名就能把一封信认证通过，From 里显示的却是你公司的地址。DMARC 要问的是另一件事：那次通过的 SPF 或 DKIM，是不是就来自这个可见地址所属的域名。[DMARC 规范 RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) 把这一点叫作对齐（alignment）。具体取决于策略怎么设：两个域名要么完全一致，要么同属一个组织域名，比如 `example.com` 下的两个子域名。

只要 DMARC 策略有效，一封邮件走通任意一条对齐的认证路径，DMARC 就算通过：

```mermaid
flowchart TD
    S["SPF 通过，且域名与 From 对齐"] --> D["任一条路径走通，DMARC 即通过"]
    K["DKIM 通过，且域名与 From 对齐"] --> D
    D --> R["收件方仍按自己的投递规则处理"]
```

加一条策略，可能刚好解决 MailRoute 描述的这些情况。但签名本身坏了，加记录修不好；发信域名跟你这个域名毫无关系，它也没法让两者对上。另外，群发新规要求 SPF 和 DKIM 双双通过，比 DMARC 自己“任一条通过即可”的标准更严。

## 先看清策略，再照抄修复方案

从退信本身看起。里面如果带着前面那个缺少认证的错误，就去找管邮箱和 DNS 的人，查一查你 From 地址里的那个域名。以 `example.com` 为例，MailRoute 建议这样查：

```bash
dig +short TXT _dmarc.example.com
```

结果里出现以 `v=DMARC1` 开头的记录，说明 DMARC 策略已经发布，但记录里的内容还得逐项核。如果你从子域名发信，父域名的策略可能照样管着你；只在子域名上查一次、拿到空结果，判断不了什么。接收方怎么找到适用的策略，RFC 9989 里有说明。

如果确实没有可用策略，服务商也确认了认证是对齐的，MailRoute 建议在 `_dmarc` 下加一条这样的 TXT 记录：

```text
v=DMARC1; p=none
```

这条记录只是把策略公布出去，并不要求接收方因为 DMARC 失败就隔离或拒收邮件。排查期间，已有的策略请原样保留。把 `p=reject` 改成 `p=none`，等于自己把原本声明的处理力度降了下来；在同一个名字下再塞一条 DMARC 策略记录，还可能让策略查找整个失效。

> **Info:**
>
> 上面这条最简记录并没有要求汇总报告。照 MailRoute 的说法，容易以为有 `p=none` 就够了，但光有 `p=none`，接收方并不知道报告该往哪发。[规范要求写明 `rua` 目的地](https://www.rfc-editor.org/rfc/rfc9989.html)，才算真的请求了汇总报告。想要这份反馈，就让服务商配一个你能长期盯着的目的地。

## 重发成功，只能算一次结果

MailRoute 说，同一个域名发出的信，这封失败，下一封可能就成了。所以重发一次成功，并不能说明它报告的这种时好时坏已经过去。改完配置后，去看收到邮件里的认证结果，同时继续盯着退信。

[Hacker News 上的讨论](https://news.ycombinator.com/item?id=50416158)里也有管理员反映类似情况，还有人说自己的域名明明有 DMARC 策略，照样出问题。这些说法既说不了问题有多普遍，也说不清每次失败是不是同一个原因。看到退信，先读错误信息，别急着认定是缺 DMARC。

我的看法是，哪怕一个域名平时只发发日常往来邮件，也值得查一遍。让服务商确认你这个域名适用哪条 DMARC 策略、认证状态如何，然后再看投递是否正常。DMARC 只负责确认“这个域名有没有被授权这么用”，至于收不收这封信，还是收件方说了算。