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 失敗 → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。