本文協助您評估並選擇支援的非 Microsoft 電子郵件安全服務與 Microsoft 365 整合方式，包括每種選項的權衡與可支援性考量。
雖然 Microsoft 提供完整的電子郵件安全平台，但我們了解到部分客戶會採用 深度防禦策略， 透過新增非 Microsoft 的安全服務來加強郵件安全。 在 Microsoft 365 中整合非 Microsoft 安全服務有兩項考量：
非 Microsoft 服務是否提升了組織的安全態勢，以及由此帶來的權衡。 例如：
- 成本更高。
- 更複雜。
- 隨著加入的產品愈多，偽陽性率（將良品誤判為不良品的比率）就會愈高。
- 非 Microsoft 的安全服務如何整合端對端。 例如：
- 非 Microsoft 服務應該提供使用者體驗，不需要用戶思考要使用哪種隔離措施。
- 非Microsoft服務應與現有的安全運營 (安全運營（Security Operations）) 流程與工具整合。 例如，安全資訊與事件管理（SIEM）、安全協同運作、自動化與回應（SOAR）等。
注意事項
Email 安全是一個對抗性的領域。 隨著現成的網路釣魚工具和攻擊套件興起，攻擊手法迅速演進並變形。 適用於 Office 365 的 Microsoft Defender 是 Microsoft Defender 的一部分，這是我們多層次、資安前與資安後的企業資安策略。
無論電子郵件保護層級多少，總保護永遠無法達到百分之百。
非 Microsoft 服務如何掃描並處理電子郵件。 通常，非 Microsoft 的安全服務會建議以下三種整合選項，而 Microsoft 目前並非所有選項都能同等支持。
透過 DNS 郵件路由進行整合（MX 記錄指向非 Microsoft 服務）
強化連接器過濾讓 Microsoft 365 能辨識經過其他郵件服務的訊息原始來源，這些訊息在抵達 Exchange Online 之前。 在 Microsoft 365 之前使用非 Microsoft 服務的增強型連接器過濾，詳見《Exchange Online 連接器增強過濾》，且 Microsoft 完全支援此功能。 認證接收鏈（ARC）會 保留郵件透過中介服務時的電子郵件認證結果。 支援 ARC 的電子郵件安全廠商效果最佳，但也有限制。 例如，請避免使用 Safe Links 搭配也會重寫連結的非 Microsoft 服務來檢查及封裝連結。 雙重連結包裝可能會導致安全連結無法驗證連結狀態、無法引爆連結以偵測威脅，且可能會觸發僅供一次使用的連結。 我們建議在非 Microsoft 服務中停用連結包裝功能。
關於在 Exchange Online 之前透過非 Microsoft 雲端服務路由郵件的更多背景，請參閱「使用 Exchange Online 管理非 Microsoft 雲端服務郵件流」。
透過 Microsoft 圖形 API 整合
Important
此整合通常需要授權非 Microsoft 服務完全存取信箱。 在授予此權限前，務必了解非 Microsoft 服務的安全性與支援措施。
部分非 Microsoft 服務會驗證身分並使用 Microsoft 圖形 API，在郵件訊息送達使用者信箱後加以掃描。 利用Microsoft 圖形 API掃描送達後的訊息，也讓非Microsoft服務能移除他們認為惡意或不受歡迎的訊息。
透過收發郵件路由進行整合
進出郵件路由允許 MX 記錄指向 Microsoft 365。 然而，非 Microsoft 的服務會在 Microsoft 365 電子郵件保護與處理之後執行，如下圖所示：
提示
連接器的進階篩選不適用於郵件離開後又重新進入 Microsoft 365 的雙向路由。 連接器強化過濾設計適用於非 Microsoft 服務置於郵件路徑中 Microsoft 365 之前的情況（MX 紀錄指向非 Microsoft 服務）。 此配置可讓完整的電子郵件保護機制運作，同時智慧地避免因非 Microsoft 服務的傳送基礎結構而產生的偽造誤判（假陽性）。 你無法用增強型連接器過濾來本質上信任所有來自 Microsoft 365 IP 位址的訊息。
進出郵件路由要求訊息離開 Microsoft 365 服務邊界。 來自非 Microsoft 服務的訊息會被 Microsoft 365 視為全新訊息。 這種行為導致以下問題與複雜性：
大多數報告工具中訊息會被計算兩次，包括 Explorer (Threat Explorer) 、Advanced Hunting 以及 AIR) (自動調查與回應。 這種行為使得訊息的判斷與行動難以正確關聯。
由於傳回 Microsoft 365 的郵件很可能無法通過電子郵件驗證檢查，因此這些郵件可能會被判定為偽冒郵件（誤判）。 部分非Microsoft服務建議使用郵件流規則 (傳輸規則) 或 IP 連線過濾來解決此問題，但這可能導致誤報。
最重要的是，適用於 Office 365 的 Defender 的機器學習運作效率不如預期。 機器學習演算法依賴準確的數據來做出內容決策。 不一致或竄改的資料會負面影響學習過程，進而降低 適用於 Office 365 的 Defender 的整體效能。 範例包含：
- 聲譽：隨著時間推移，機器學習模型會發現與好壞內容相關的元素 (IP 位址、發送網域、網址等 ) 。 當非 Microsoft 服務的訊息回傳時，最初的發送 IP 位址不會被保留，這會降低 IP 位址在正確判斷上的效力。 此行為也可能影響向 Microsoft 提交的誤報與誤判郵件，詳見步驟 3：偽陰性與假陽性郵件提交。
- 訊息內容修改：許多電子郵件安全服務會新增訊息標頭、加入免責聲明、修改訊息內容，及/或重寫郵件中的網址。 機器學習可能會意外判定帶有這些修改的訊息是惡意的，因為零 時刻自動清除 (ZAP) 發現並移除了惡意訊息，而這些惡意訊息恰巧包含這些修改。
基於以上原因，我們強烈建議避免此配置，並與非 Microsoft 服務供應商合作，使用本文所述的其他整合選項。 然而，若您必須採用進出郵件路由，我們強烈建議以下設定與操作以最大化您的保護態勢：
設定適用於 Office 365 的 Defender 原則動作，以隔離所有負面裁定。 雖然這種設定可能不如使用 Junk Email 資料夾友善，但垃圾郵件的操作只會在最終送達信箱時發生。 原本要送到 Junk Email 資料夾的郵件，卻被寄到非 Microsoft 服務。 如果/當這則訊息回傳給Microsoft時，無法保證原始判決 (例如垃圾郵件) 會被保留。 這種行為導致整體效能下降。
提示
檢視原始判定結果的郵件流程規則（傳輸規則）並不理想，因為這類規則可能會帶來其他問題，並造成成效方面的挑戰。
針對來自非 Microsoft 服務的郵件覆寫偽造設定，將誤判降到最低。 例如，如果非 Microsoft 服務的 IP 位址為 172.17.17.35，請建立兩個租用戶允許/封鎖清單中已允許的偽造寄件者項目，一個為外部項目，另一個為內部項目，如下列螢幕擷取畫面所示：
如果你以後離開非 Microsoft 的保護服務或更改其運作方式，務必移除這些覆寫項目。
提交給 Microsoft 的漏報(允許不良郵件)和誤判郵件，應使用郵件的原始版本，而非從非 Microsoft 服務傳回的版本。 歸因於非 Microsoft 服務的誤判，應傳送給該非 Microsoft 服務。 這項需求管理起來相當複雜：
- Microsoft 漏報(初次接收時遺漏)：您需要在郵件傳送到信箱之前的複本。 如果非 Microsoft 服務中有隔離的複本可用，請提交該複本。
- Microsoft + 非 Microsoft 服務漏報：如果兩個服務都漏掉，建議先向 Microsoft 回報原始項目，並將收件人信箱中的項目回報給非 Microsoft 服務。 從非Microsoft服務回傳到 Microsoft 365 的項目包含非Microsoft服務的細節 (例如非Microsoft服務的發送 IP 位址、自訂標頭等 ) 這可能導致機器學習效能下降。
- Microsoft 誤判：如果 Microsoft 在非 Microsoft 服務之前攔截到郵件，則從隔離區提交此複本會有效。
- 非 Microsoft 服務誤判：如果非 Microsoft 服務偵測到訊息，你必須將訊息提交給他們，因為 Microsoft 無法修正這個問題。
整合非 Microsoft 訊息回報工具
適用於 Office 365 的 Defender 具有使用者回報設定，可搭配支援的 Outlook 版本中的內建回報按鈕使用。
鑑於非Microsoft安全服務可能包含自己的誤報與漏報工具與流程， (包含用戶教育/意識推廣) ，適用於 Office 365 的 Defender 支援非Microsoft通報工具的提交。 這項支援有助於簡化向 Microsoft 回報誤判為陽性與誤判為陰性的流程，並讓您的安全性作業（SecOps）團隊能充分運用 Microsoft Defender 的事件管理與自動化調查與回應（AIR）。
欲了解更多資訊，請參閱 非 Microsoft 報告工具選項。
提示
在 適用於 Office 365 的 Defender Plan 2 的攻擊模擬訓練中，非 Microsoft 工具回報的模擬訊息不會被捕捉在攻擊模擬報告中。