[ 送達率和寄件者規則 ]

Outlook大容量寄件者要求:區分消費者郵件和企業郵件

診斷消費者服務範圍內的Outlook .com 大量身份驗證失敗,而不是應用企業郵件假設。

由EmailAuth研究團隊提供 · 3 分鐘閱讀

[ 重點 ]

  • 確定 Microsoft 消費者郵箱服務,而不僅僅是Outlook應用程式。
  • DMARC通行證可以與失敗的單獨SPF要求共存。
  • 在更改身份驗證之前保留實際的拒絕和路由。
在此頁面上

“Outlook” can mean a desktop application, a consumer mailbox or an organization's Microsoft 365 environment. Those are not interchangeable policy scopes. Start with the actual receiving service and diagnostic before using a high-volume checklist to explain a failed message.

確定消費者服務及其當前需求

Microsoft 目前針對 550 5.7.515 的支援文章介紹了Outlook .com 和相關消費者服務,包括 Hotmail、Live.com 和 MSN。它會將大容量寄件者識別為向使用可見網域中相同網域的服務發送 5,000 則或更多訊息 5322.來自 地址。其支持措辞指出,两者 SPF 和 DKIM must pass, and that a published DMARC 政策至少 p=none 需要DMARC通行證。 Microsoft 550 5.7.515 guidance.

更新後的公告規定拒絕執行將於 2025 年 5 月 5 日開始。其最初的僅垃圾郵件計劃被取消;請勿將該被取代的段落視為當前的應對政策。 微軟更新公告.

早些時候的公告描述了每日交易量並使用了「超過 5,000 個」。不要圍繞邊界措辭建立豁免:目前的支持指南使用 5,000 或更多。您也不應該從此支援頁面發明重置期或永久分類規則。解釋案例時記錄版本和實際接收的診斷結果。

Separate protocol success from the provider gate

參考: RFC 9989 §4.4, RFC 9989 §5.3.5.

DMARC可以透過對齊成功 DKIM簽名 even when SPF fails. That protocol outcome does not satisfy a separate requirement that both underlying mechanisms pass. Conversely, SPF and DKIM may both pass for domains unrelated to the visible From and leave DMARC failing. Keep all three results and the identities behind them.

對於直接服務產生的訊息,記錄發送 IP, 信封寄件人 domain, From domain, DKIM d= domain and 選擇器。驗證目前的DNS和最終簽名的訊息,而不僅僅是設定畫面。使用實際的協定名稱: SMTP MAIL FROM 是RFC 5321信封標識,而可見的 From 屬於RFC 5322 。

將拒絕視為證據,而不是修復腳本

參考: RFC 8601 §5.

550 5.7.515 拒絕表示寄件者的網域不符合所需的身份驗證等級。保留整個診斷、時間、受影響的收件者和訊息識別碼。不要透過將每個可用的提供者新增至SPF或停用來回應 DMARC執行 without understanding the failing identity.

比較受影響和未受影響的流。計費服務可能具有正確的自訂簽名設置,而活動服務仍然僅使用其自己的網域進行簽署。如果涉及轉送或其他中介,請保留路由和轉換。直郵假設可能無法解釋間接路徑,且複製 Authentication-Results 線路不能取代可信任接收者證據。

Work through a synthetic diagnostic

參考: RFC 9989 §5.3.5.

想像一條受控訊息,其SPF結果為失敗,其DKIM結果為通過 結盟,其DMARC結果為通過。 DMARC結果是內部一致的。根據微軟規定的大批量要求, SPF故障仍然需要修復。這是一個合乎邏輯的例子,而不是微軟的拒絕。

下一步是確定評估的信封寄件者是否授權實際連接 IP。經批准的修正後,透過相同的預期路線重新測試並保留新的結果。不要重複使用舊通行證作為已更改訊息或路線的證據。

Keep enterprise cases on their own evidence path

Microsoft 365租用戶可以套用自己的入站原則和連接器。使用Outlook應用程式的收件者不會使其組織受到使用者文章的嚴格控制。對於企業案例,收集租戶的診斷和策略上下文,而不是假設 5.7.515 解釋了每個 5.7.x 回應。

關閉受影響的服務、寄件人域、觀察到的機制結果和更正的路由。這裡沒有聲稱進行即時 Microsoft 郵箱測試,並且身份驗證合規性仍然與收件匣放置不同。

[ 外帶 ]

在更改身份驗證之前保留實際的拒絕和路由。

[ 按角色 ]

這對您意味著什麼

選擇您的角色以執行後續實際步驟。

IT/郵件管理員

保留每次認證結果

DMARC本身就可以隱藏單獨的機制故障。

後續步驟

  1. Capture full diagnostics.
  2. Map envelope and From identities.
  3. Retest the corrected route.

CISO / SecOps

Avoid policy weakening by guesswork

拒絕是調查的理由,而不是擴大授權的理由。

後續步驟

  1. 仔細檢查SPF變化。
  2. 保留中間證據。
  3. Separate tenant policy from consumer guidance.

創辦人/非技術人員

Scope the incident before escalating

消費者案件和企業案件需要不同的證據。

後續步驟

  1. 識別郵箱服務。
  2. 追蹤受影響的流。
  3. Avoid a universal Outlook label.

[ 常見問題解答 ]

常見問題

使用Outlook應用程式是否可以識別接收策略?

否。確定實際的郵箱服務和診斷。

Which services does the 5.7.515 article cover?

Outlook .com 和相關的 Microsoft 消費者電子郵件服務。

目前的提供者指南

Can DMARC pass while SPF fails?

是的,透過一致的成功DKIM簽章。

RFC 9989 §5.3.5

這一定能滿足消費者的大量需求嗎?

不可以。 Microsoft 的支援文章需要SPF和DKIM才能通過。

目前的提供者指南

Should 5,000 exactly be treated as an exemption?

否。当前的支持措辞使用 5,000 或更多。

目前的提供者指南

這是否建立了永久的高容量狀態規則?

不可以。請勿從引用的支援頁面推斷分類生命週期。

目前的提供者指南

管理員是否應該停用DMARC來修復拒絕問題?

先診斷失敗的身份;不要把政策削弱當作盲目修復。

合成 SPF 失敗範例是否已傳送給 Microsoft?

不。它說明了協議邏輯和提供者要求之間的差異。

[ 來源 ]

來源

  1. RFC 8601

    部分 §5

  2. RFC 9989

    部分 §4.4 · §5.3.5

  3. 微軟官方要求

    部分 高容量(大)发件人的定义是什么? · 認證要求

  4. 微軟更新官方要求

    部分 執行時間表

[ 詞彙表 ]

詞彙表

消費者信箱
提供者消費者服務中的郵箱而不是企業租戶中的郵箱。
5322.來自
郵件的「寄件者」標頭中顯示的作者地址。
5321.郵件寄件人
郵件傳輸期間所使用的SMTP信封寄件者身分。

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

知識庫