所有到 Office 365 的外部郵件都無法通過 SPF，在混合部署中被 EOP 標記為垃圾郵件
簡而言之：由於 EOP（Exchange Online Protection）將電子郵件標記為垃圾郵件 (SCL5) 和 SPF 失敗，因此合法電子郵件會降落在垃圾文件夾中。客戶端域 (contoso.com) 的所有外部域（例如 gmail.com/hp.com/microsoft.com）都會發生這種情況。
背景資料：
我們正開始將郵箱遷移到 Office 365 (Exchange Online)。這是混合部署/富共存配置，其中：
- 本地 = Exchange 2003（舊版）和 2010（為混合部署而安裝）
- 場外 = Office 365 (Exchange Online)
- EOP 配置用於 SPF 檢查。
- MX 記錄指向本地，因為我們尚未完成將所有郵箱從本地遷移到 Exchange Online。
問題是當外部使用者向組織中的 Office 365 郵箱發送電子郵件時（郵件流：外部 -> 郵件網關 -> 本地郵件伺服器 -> EOP -> Office 365），EOP 執行 SPF 查找和硬/軟使用從其接收郵件的郵件網關的面向外部的 IP 地址失敗的郵件。
（本地郵箱不顯示此問題；只有遷移到 Office 365 的郵箱才會出現。）
插圖：
範例 1：從 Microsoft 到 O365
Authentication-Results: spf=fail (sender IP is 23.1.4.9) smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com; dkim=none (message not signed) header.d=none; Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate 23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9; helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5範例 2：從 HP 到 O365
Authentication-Results: spf=none (sender IP is 23.1.4.9) smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none (message not signed) header.d=none; Received-SPF: None (protection.outlook.com: hp.com does not designate permitted sender hosts) X-MS-Exchange-Organization-SCL: 5範例 3：從 Gmail 到 O365
Authentication-Results: spf=softfail (sender IP is 23.1.4.9) smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com; dkim=fail (signature did not verify) header.d=gmail.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning gmail.com discourages use of 23.1.4.9 as permitted sender) X-MS-Exchange-Organization-SCL: 5對於帶有 X-Forefront-Antispam-Report 的郵件標頭，請參閱http://pastebin.com/sgjQETzM
注意：23.1.4.9 是本地混合 Exchange 2010 伺服器連接器到 Exchange Online 的公共 IP 地址。
在混合部署的共存階段，我們如何阻止外部電子郵件被 EOP 標記為垃圾郵件？
$$ 2015-12-12 Update $$
此問題已由 Office 365 支持（升級/後端團隊）修復，因為它與我們的設置無關。
我們被建議如下：
- 將 EOP 允許列表中的公共 IP 列入白名單（已嘗試。它沒有幫助。）
- 為我們的域添加 SPF 記錄：“v=spf1 ip4:XXX.XXX.XXX.XXX ip4:YYY.YYY.YYY.YYY include:spf.protection.outlook.com -all”（不要認為這個建議是有效的因為 EOP 不應該根據我們的 SMTP IP 地址檢查 gmail.com，因為它沒有在 gmail.com 的 SPF 記錄中指定。這似乎不是 SPF 的工作方式。）
- 確保啟用 TLS（見下文）
關鍵部分是第三點。“如果未啟用 TLS，來自本地 Exchange 的傳入電子郵件將不會被標記為內部/信任電子郵件，並且 EOP 將檢查所有記錄，”支持人員說。
支持人員通過以下行從我們的郵件標頭中確定了 TLS 問題：
- X-MS-Exchange-Organization-AuthAs：匿名
這表示 EOP 收到電子郵件時未啟用 TLS。EOP 沒有將傳入的電子郵件視為信任電子郵件。正確的應該是這樣的：
- X-MS-Exchange-Organization-AuthAs：內部
但是，這不是由我們的設置引起的；支持人員通過驗證來自 Exchange 2010 混合伺服器的詳細 SMTP 日誌，幫助我們確保設置正確。
大約在同一時間，他們的後端團隊解決了這個問題，但沒有讓我們知道究竟是什麼原因造成的（不幸的是）。
在他們修復它之後，我們發現消息頭有一些重大變化，如下所示。
對於從 Exchange 2003 到 Office 365 的內部發起郵件：
- X-MS-Exchange-Organization-AuthAs：內部（它是“匿名的”）
- SCL=-1（SCL=5）
- Received-SPF: SoftFail (它是一樣的)
對於 Office 365 的外部郵件（例如 gmail.com）：
- X-MS-Exchange-Organization-AuthAs：匿名（相同）
- SCL=1（原來是 SCL=5）
- Received-SPF: SoftFail (它是一樣的)
儘管 gmail.com（外部）對 Office 365 的 SPF 檢查仍然失敗，但支持人員表示沒問題，所有郵件都會進入收件箱而不是垃圾文件夾。
附帶說明一下，在故障排除過程中，後端團隊發現了一個看似次要的配置問題——我們在 IP 允許列表中定義了來自入站連接器的 IP（即 Exchange 2010 混合伺服器的公共 IP）（由另一個 Office 365 支持人員建議）人作為故障排除步驟）。他們讓我們知道我們不需要這樣做，實際上這樣做會導致路由問題。他們評論說，在初次通過時，電子郵件沒有被標記為垃圾郵件，因此這裡也可能存在問題。然後，我們從 IP 允許列表中刪除了該 IP。（但是，垃圾郵件問題在進行 IP 允許列表設置之前就存在。我們認為允許列表不是原因。）
總之，“應該是EOP機制，”支持人員說。因此，整個事情應該是由它們的機制引起的。
對於任何感興趣的人，可以在此處查看與他們的支持人員之一的故障排除執行緒：https ://community.office365.com/en-us/f/156/t/403396
您確定郵件流直接從您的混合伺服器流向 O365 嗎？
當您執行混合嚮導時，它應該已經在本地和 O365 中創建了連接器，它將森林之間的郵件流作為內部郵件進行處理。這意味著它將繞過 EOP/垃圾郵件檢查，您將永遠不會看到那些 SPF 消息。
如果您的邊緣設備正在修改標頭，這可能會導致您的問題 - 在您的伺服器和 O365 之間，不應修改消息標頭。確保您沒有可能覆蓋混合嚮導創建的連接器的現有連接器。您始終可以刪除已創建的現有連接器並重新執行嚮導以重新創建它們。
檢查您在 Exchange 中的傳輸規則，並確保它們在轉到 O365 之前沒有修改郵件，如果它們被禁用並再次測試以確保這些不是您的問題。
最後（或者可能是第一個）檢查您的聯合是否配置正確。如果不是那可能是您的郵件未得到正確處理的原因。這也是重新執行混合嚮導可以為您提供幫助的地方。