EOP 中的電子郵件驗證

提示

您知道您可以免費試用Office 365方案 2 的Microsoft 365 Defender功能嗎？ 使用 Microsoft Defender 入口網站試用中樞的 90 天適用於 Office 365 的 Defender試用版。 在這裡瞭解誰可以註冊和 試用條款。

Email驗證 (也稱為電子郵件驗證) 是一組標準，會嘗試阻止來自偽造寄件者的電子郵件， (也稱為詐騙) 。 Microsoft 365 使用下列標準來驗證輸入電子郵件：

Email驗證會驗證寄件者 (的電子郵件訊息，例如， laura@contoso.com) 合法，而且來自該電子郵件網域的預期來源 (例如，contoso.com) 。

本文章的其餘部分說明這些技術的運作方式，以及 EOP 如何使用它們來檢查輸入電子郵件。 如需在 DNS 中設定 SPF、DKIM 和 DMARC 記錄的相關資訊，請參閱先前的連結。

使用電子郵件驗證以協助避免詐騙

DMARC 會透過檢查郵件中的寄件者位址來防止詐騙。 寄件者位址是使用者在其電子郵件用戶端中看到的寄件者電子郵件地址。 目的地電子郵件組織也可以驗證電子郵件網域是否已通過 SPF 或 DKIM。 換句話說，來源網域是寄件者位址中的有效來源，因此發件人的電子郵件地址不會遭到詐騙。

不過，SPF、DKIM 和 DMARC (統稱為 電子郵件驗證 原則) 的 DNS 記錄是選擇性的。 具有強式電子郵件驗證原則的網域會受到保護，免于詐騙。 但是，電子郵件驗證原則較弱或完全沒有原則的網域是詐騙的主要目標。

缺乏強式電子郵件驗證原則是個大問題。 雖然組織可能無法瞭解電子郵件驗證的運作方式，但攻擊者完全瞭解並利用它們。 因為網路釣魚疑慮，以及強式電子郵件驗證原則的採用率有限，Microsoft 使用隱含電子郵件驗證來檢查輸入電子郵件。

隱含電子郵件驗證是一般電子郵件驗證原則的延伸模組。 這些延伸模組包括：寄件者信譽、寄件者歷程記錄、收件者歷程記錄、行為分析，以及其他進階技術。 如果沒有來自這些擴充功能的其他訊號，從未使用電子郵件驗證原則的網域傳送的訊息會標示為詐騙。

若要查看 Microsoft 的一般公告，請參閱網路釣魚的範圍第 2 部分 - Microsoft 365 中增強的反詐騙保護`。

複合驗證

如果網域沒有傳統的 SPF、DKIM 和 DMARC 記錄，這些記錄檢查無法傳達足夠的驗證狀態資訊。 因此，Microsoft 開發了用於隱含電子郵件驗證的演算法。 此演算法會將多個訊號組合成單一值，稱為複合驗證，或簡稱為 compauth。 系統會在郵件標頭的 Authentication-Results 標頭中，加上 compauth 值戳記。

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

這些值會在 Authentication-results 郵件標頭中說明。

透過檢查訊息標頭，系統管理員和使用者可以判斷 Microsoft 365 如何判斷寄件者遭到詐騙。

為什麼電子郵件驗證不一定足以停止詐騙

只依靠電子郵件驗證記錄來判斷內送郵件是否為詐騙，有下列限制：

  • 來源網域可能缺少必要的 DNS 記錄，或記錄的設定不正確。
  • 來源網域具有正確設定的 DNS 記錄，但是該網域與 [寄件者] 地址中的網域不相符。 SPF 和 DKIM 不需要在 [寄件者] 地址中使用網域。 攻擊者或合法服務可以註冊網域、設定網域的 SPF 和 DKIM，以及在 From 位址中使用不同的網域。 來自此網域中寄件者的訊息會傳遞 SPF 和 DKIM。

複合驗證可以藉由讓無法通過電子郵件檢查的郵件通過，以解決這些限制。

為了簡單起見，以下範例著重於電子郵件驗證結果。 其他後端情報因素可識別通過電子郵件驗證的郵件為詐騙，或將電子郵件驗證失敗的郵件視為合法者。

例如，fabrikam.com 網域沒有 SPF、DKIM 或 DMARC 記錄。 來自 fabrikam.com 網域中寄件者的郵件無法通過複合驗證 (請記下 compauth 值和原因)：

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

如果 fabrikam.com 在沒有 DKIM 記錄的情況下設定 SPF，郵件就可以通過複合驗證。 通過 SPF 檢查的網域會與 [寄件者] 位址中的網域對應：

Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

如果 fabrikam.com 在沒有 SPF 記錄的情況下設定 DKIM 記錄，該郵件就會通過複合驗證。 DKIM 簽章中的網域會與 [寄件者] 位址中的網域對應：

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

如果 SPF 或 DKIM 簽章中的網域與 [寄件者] 地址中的網域不相符，則該郵件無法通過複合驗證：

Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

傳送未經驗證電子郵件的合法寄件者解決方案

Microsoft 365 會追蹤誰傳送未經驗證電子郵件到您的組織。 如果服務認為寄件者不合法，則會將來自此寄件者的訊息標示為複合驗證失敗。 若要避免此決策，您可以使用本節中的建議。

為您擁有的網域設定電子郵件驗證

您可以使用這個方法，在您擁有多個租用戶或與多個租用戶互動的案例中，解決組織內部詐騙和跨網域詐騙。 其也有助於解決跨網域詐騙，您在其中傳送郵件給 Microsoft 365 內的客戶，或其他提供者主控的第三方。

Microsoft 不會針對 SPF、DKIM 和 DMARC 記錄提供詳細實作指南。 不過，該資訊可在線上取得。 也有第三方公司可專門協助您的組織設定電子郵件驗證記錄。

您不知道電子郵件的所有來源

許多網域並不會發佈 SPF 記錄，因為它們不知道在其網域中郵件的所有電子郵件來源。 首先，發佈包含您知道的所有電子郵件來源的 SPF 記錄 (特別是公司流量位於) 的位置，然後在 SPF 記錄中 ~all () 發佈強制規則值「軟性失敗」。 例如：

fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

此範例表示來自公司基礎結構的電子郵件會通過電子郵件驗證，但來自未知來源的電子郵件會回復為「軟性失敗」。 一般而言，電子郵件伺服器會設定為傳遞這些訊息。

Microsoft 365 會將來自公司基礎結構的輸入電子郵件視為已驗證。 來自無法識別來源的電子郵件若隱含驗證失敗，仍可能會被標示為詐騙。 不過，此行為仍然是 Microsoft 365 標示為詐騙的所有電子郵件的改進。

當您開始使用 SPF 後援原則 ~all 之後，您就可以逐漸探索及包含更多郵件來源，然後使用更嚴格的原則更新您的 SPF 記錄。

設定允許傳送未經驗證電子郵件的寄件者

您也可以使用詐騙情報深入解析 和 租用戶允許/封鎖清單 以允許寄件者將未經驗證的郵件傳送至您的組織。

對於外部網域，偽裝的使用者是寄件者地址中的網域，而傳送基礎結構是以下值之一：

  • 來源 IP 位址 (分為 /24 CIDR 範圍)
  • 反向 DNS (PTR) 記錄的組織網域。
  • 已驗證的 DKIM 網域。

為寄件者/收件者配對建立允許項目

若要略過某些寄件者的垃圾郵件篩選，但不要使用惡意程式碼或高信賴度網路釣魚，請參閱 在 Microsoft 365 中建立安全的寄件者清單。

要求寄件者為您未擁有的網域設定電子郵件驗證

有鑑於垃圾郵件和網路釣魚問題，Microsoft 建議針對所有電子郵件組織進行電子郵件驗證。 您可以要求來源網域中的系統管理員設定其電子郵件驗證記錄，而不是在您的組織中設定手動覆寫。

  • 即使他們過去不需要發佈電子郵件驗證記錄，如果他們傳送電子郵件至 Microsoft，就應該這麼做。
  • 設定 SPF 來發佈網域的傳送 IP 位址，並設定 DKIM (若可用) 來數位簽署郵件。 他們應該考慮設定 DMARC 記錄。
  • 如果他們使用大量寄件者代表他們傳送電子郵件，則要確認 [寄件者] 地址中的網域 (如果屬於他們) 與通過 SPF 或 DMARC 的網域相符。
  • 確認下列位置 (如果他們使用這些位置) 包含在 SPF 記錄中：
    • 內部部署電子郵件伺服器。
    • 軟體即服務 (SaaS) 提供者傳送的電子郵件。
    • 從雲端主控服務 (Microsoft Azure、GoDaddy、Rackspace、Amazon Web Services 等等) 傳送的電子郵件。
  • 針對 ISP 主控的小型網域，根據 ISP 的指示來設定 SPF 記錄。

雖然一開始可能很難讓傳送網域進行驗證，但成功的電子郵件傳遞會強制他們這麼做，因為有更多電子郵件篩選器會垃圾郵件或甚至拒絕其電子郵件。 此外，他們的參與可協助抵禦網路釣魚，並能降低組織或電子郵件傳送目標組織中網路釣魚的可能性。

基礎結構提供者 (ISP、ESP 或雲端主控服務) 的資訊

如果您主控網域的電子郵件，或提供可傳送電子郵件的主控基礎結構，您應該執行下列步驟：

  • 請確認您的客戶擁有文件，其中說明客戶應如何設定其 SPF 記錄
  • 即使客戶未明確設定 (使用預設網域登入)，仍考慮在外寄電子郵件中簽署 DKIM 簽章。 您甚至可以使用 DKIM 簽章對電子郵件進行雙重簽署 (如果已經設定了客戶的網域，則為第一次，第二次使用您公司的 DKIM簽章)

即使您驗證來自平臺的電子郵件，也不保證會傳遞給 Microsoft。 但是，此設定可確保 Microsoft 不會垃圾郵件，因為它未經過驗證。

如需服務提供者最佳作法的詳細資訊，請參閱適用服務提供者的 M3AAWG 行動訊息最佳做法。

瞭解 Office 365 如何使用 SPF 並支援 DKIM 驗證：