Microsoft 365 中的電子郵件驗證

發行項
10/02/2024
適用於:

✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

提示

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

身為Microsoft 365 組織，其信箱位於 Exchange Online 中，或是獨立 Exchange Online Protection (EOP) 組織，而不需要 Exchange Online 信箱，保護您網域中發件者的電子郵件完整性非常重要。收件者應該確信來自您網域中發件者的郵件真的來自您網域中的發件者。

Email 驗證 (也稱為電子郵件驗證) 是一組標準，可識別並防止來自偽造發件者的電子郵件訊息傳遞， (也稱為詐騙) 。詐騙寄件者通常用於商務電子郵件洩露 (BEC) 、網路釣魚和其他電子郵件攻擊。這些標準包括：

寄件者原則架構 (SPF) ：指定有權傳送網域郵件的來源電子郵件伺服器。
DomainKeys 識別郵件 (DKIM) ：使用網域以數位方式簽署訊息的重要元素，以確保郵件在傳輸過程中未遭到變更。
以網域為基礎的訊息驗證、報告和一致性 (DMARC) ：指定對網域中發件者進行 SPF 或 DKIM 檢查失敗之訊息的動作，並指定在報告) (傳送 DMARC 結果的位置。
已驗證的接收鏈結 (ARC) ：由修改傳輸中訊息的已知服務保留原始的電子郵件驗證資訊。目的地電子郵件伺服器可以使用此資訊來驗證否則會使 DMARC 失敗的訊息。

請務必瞭解，這些標準是 相互依存的建置組塊 ，可 共同運作 ，以提供最佳的電子郵件防護來防範詐騙和網路釣魚攻擊。 任何小於所有電子郵件驗證方法的動作都會產生不標準的保護。

若要針對 Exchange Online 或獨立 Exchange Online Protection (EOP) 組織中具有信箱的Microsoft 365 組織傳送的郵件設定電子郵件驗證，Exchange Online 請參閱下列文章：

若要防止 因服務修改 傳送至您Microsoft 365 組織的輸入郵件而導致電子郵件驗證失敗，請參閱設定受信任的ARC密封器。

本文的其餘部分說明：

因特網電子郵件為何需要驗證
SPF、DKIM 和 DMARC 如何一起運作以驗證電子郵件訊息發件者
Microsoft如何使用電子郵件驗證來檢查傳送至 Microsoft 365 的輸入郵件
如何避免將郵件傳送至 Microsoft 365 時發生電子郵件驗證失敗

提示

作為本文的附隨者，請參閱我們的適用於 Office 365 的 Microsoft Defender 設定指南，以檢閱最佳做法並防範電子郵件、連結和共同作業威脅。功能包括安全連結、安全附件等等。如需以您的環境為基礎的自定義體驗，您可以在 Microsoft 365 系統管理中心中存取適用於 Office 365 的 Microsoft Defender 自動化設定指南。

因特網電子郵件為何需要驗證

根據設計，因特網上的簡易郵件傳送通訊協定 (SMTP) 電子郵件不會嘗試驗證郵件寄件者是否為其所宣告的身分。

標準 SMTP 電子郵件訊息包含 郵件信封 和郵件內容：

訊息信封包含在 SMTP 伺服器之間傳輸和接收訊息的資訊。 RFC 5321 會說明郵件信封。收件者永遠不會看到郵件信封，因為它是在訊息傳輸程式期間產生。
郵件內容包含統稱為 (「郵件標頭」) 的郵件標頭欄位和郵件內容。 RFC 5322 中會描述訊息標頭。

由於這項設計，訊息具有多個發件者值：

MAIL FROM 位址 (也稱為 5321.MailFrom 位址、P1 發件者或信封發件者) 是用於在 SMTP 電子郵件伺服器之間傳輸郵件的電子郵件位址。雖然來源電子郵件伺服器可以指定不同的 Return-Path 電子郵件地址) ，但此位址通常會記錄在郵件標頭 (的 Return-Path 標頭欄位中。此電子郵件地址用於非傳遞報表 (也稱為 NDR 或退回的郵件) 。
寄件者位址 (也稱為 5322.From 位址或 P2 發件者) 是 [ 寄件者] 標頭字段中的電子郵件位址，而是電子郵件用戶端中顯示的寄件者電子郵件位址。

下列範例顯示兩部 SMTP 電子郵件伺服器之間有效訊息傳輸的簡化文字記錄：

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

在此範例中：

來源電子郵件伺服器會在 HELO 命令中將本身識別為目的地電子郵件伺服器 tailspintoys.com woodgrovebank.com。
郵件收件者為 astobes@tailspintoys.com。
郵件信封中的 MAIL FROM 位址 (用來在 SMTP 電子郵件伺服器之間傳輸訊息，) 為 dubious@proseware.com。
收件者的電子郵件客戶端中顯示的寄件者位址是 security@woodgrovebank.com。

雖然此訊息根據 SMTP 有效，但 MAIL FROM 位址 (proseware.com) 的網域與寄件者位址 (woodgrovebank.com) 中的網域不符。此郵件是詐騙的傳統範例，其中意圖可能會藉由遮罩要在網路釣魚攻擊中使用的郵件真實來源來竊取收件者。

很明顯地，SMTP 電子郵件需要協助來確認郵件寄件者是他們所宣告的身分！

SPF、DKIM 和 DMARC 如何一起運作以驗證電子郵件訊息發件者

本節說明為什麼因特網上的網域需要 SPF、DKIM 和 DMARC。

SPF：如設定 SPF 以識別您Microsoft 365 網域的有效電子郵件來源中所述，SPF 會使用 DNS 中的 TXT 記錄來識別來自 MAIL FROM 網域的有效郵件來源，以及如果目的地電子郵件伺服器收到來自未定義來源的郵件， ('hard fail' 來拒絕郵件，該怎麼辦;「軟性失敗」可接受並標示訊息) 。

SPF 問題：
- SPF 只會驗證 MAIL FROM 網域中發件人的來源。 SPF 不會考慮 [寄件者] 位址中的網域，或是 MAIL FROM 和 From 網域之間的對齊方式：
  - 攻擊者可以依照下列步驟傳送通過SPF驗證的電子郵件， (誤判) ：
    - 註冊網域 (例如，proseware.com) 和设定网域的 SPF。
    - 從已註冊網域的有效來源傳送電子郵件，並使用不同網域中的發件者電子郵件位址 (例如，woodgrovebank.com) 。
  - 代表其他網域傳送郵件的合法電子郵件服務可能會控制MAIL FROM位址。其他網域和MAIL FROM網域不相符，因此訊息無法傳遞SPF驗證 (誤判) 。
- 在訊息遇到重新導向或轉送訊息的伺服器型電子郵件轉送之後，SPF 會中斷。
  - 伺服器型電子郵件轉寄會將郵件來源從原始伺服器變更為轉寄伺服器。
  - 轉寄伺服器未獲授權從原始MAIL FROM網域傳送郵件，因此訊息無法通過SPF驗證 (誤判) 。
- 每個網域和任何子域都需要自己的個別SPF記錄。子域不會繼承父域的SPF記錄。如果您想要允許來自已定義和已使用子域的電子郵件，但防止電子郵件來自未定義和未使用的子域，則此行為會產生問題。
DKIM：如設定 DKIM 以從您的Microsoft 365 網域簽署郵件中所述，DKIM 會使用網域以數位方式簽署郵件的重要元素 (包括發件者位址) ，並將簽章儲存在郵件標頭中。目的地伺服器會確認訊息的已簽署元素未變更。

DKIM 如何協助SPF:D KIM可以驗證SPF失敗的訊息。例如：
- 來自電子郵件主控服務的訊息，其中相同的 MAIL FROM 位址會用於來自其他網域的郵件。
- 遇到伺服器型電子郵件轉寄的訊息。
因為在這些案例中，訊息標頭中的 DKIM 簽章不會受到影響或改變，所以這些訊息可以傳遞 DKIM。

DKIM 問題:D KIM 用來簽署訊息的網域不需要符合電子郵件客戶端中顯示之寄件者位址中的網域。

如同SPF，攻擊者可以依照下列步驟傳送通過 DKIM 驗證的電子郵件 (誤判) ：
- 註冊網域 (例如，proseware.com) 和设定网域的 DKIM。
- 使用不同網域中的寄件者電子郵件位址傳送電子郵件 (例如，woodgrovebank.com) 。
DMARC：如設定 DMARC 以驗證 Microsoft 365 中發件人的寄件者發件者位址網域中所述，DMARC 會使用 SPF 和 DKIM 來檢查 MAIL FROM 和 From 位址中網域之間的對齊方式。 DMARC 也會指定目的地電子郵件系統應該對 DMARC 失敗的訊息採取的動作，並識別在傳遞和失敗) (傳送 DMARC 結果的位置。

DMARC 如何協助 SPF 和 DKIM：如先前所述，SPF 不會嘗試比對 MAIL FROM 網域和發件者位址中的網域。 DKIM 不在意簽署訊息的網域是否符合 [寄件者] 位址中的網域。

DMARC 會使用 SPF 和 DKIM 來確認 MAIL FROM 和 From 位址中的網域相符，以解決這些缺陷。

DMARC 問題：在傳遞之前修改傳輸中訊息的合法服務會中斷SPF、DKIM，因而導致 DMARC 檢查。
ARC：如設定受信任的 ARC 密封器中所述，修改傳輸中訊息的合法服務可以使用 ARC 來保留已修改郵件的原始電子郵件驗證資訊。

ARC 如何協助 DMARC：目的地電子郵件系統可以將服務識別為受信任的 ARC 密封器。 ARC 接著可以使用保留的電子郵件驗證資訊來驗證訊息。

傳送至 Microsoft 365 之郵件的輸入電子郵件驗證

由於網路釣魚問題，以及因特網上的電子郵件發件者未完全採用強式電子郵件驗證原則，Microsoft 365 會使用 隱含電子郵件驗證 來檢查輸入電子郵件。隱含電子郵件驗證會使用來自其他來源的訊號來評估輸入電子郵件，以擴充一般SPF、DKIM和 DMARC 檢查。這些來源包括：

寄件人信譽。
寄件者歷程記錄。
收件者歷程記錄。
行為分析。
其他進階技術。

若要查看Microsoft關於隱含驗證的原始公告，請參閱網路釣魚海第 2 部分 - Microsoft 365 中增強的反詐騙功能。

藉由使用這些其他訊號，將無法通過傳統電子郵件驗證檢查的訊息可以傳遞隱含驗證，並允許Microsoft 365。

複合驗證

Microsoft 365 的隱含驗證檢查結果會合併並儲存在名為 複合驗證 的單一值中，簡 compauth 而言之。系統會在郵件標頭的 Authentication-Results 標頭中，加上 compauth 值戳記。 Authentication-Results 標頭會使用下列語法：

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

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

系統管理員和使用者可以檢查郵件標頭，以探索Microsoft 365 如何將寄件者識別為可疑的詐騙發件者或合法的發件者。

提示

請務必瞭解複合驗證失敗不會直接導致訊息遭到封鎖。我們的系統使用整體評估策略，以考慮訊息的整體可疑本質以及複合驗證結果。此方法旨在降低不正確封鎖來自網域之合法電子郵件的風險，這些網域可能未嚴格遵守電子郵件驗證通訊協定。此平衡方法有助於區別惡意電子郵件與只不符合標準電子郵件驗證做法的郵件發件者。

下列範例著重於僅 (值和原因) compauth 的電子郵件驗證結果。其他Microsoft 365保護技術可以將透過電子郵件驗證的郵件識別為詐騙，或將無法通過電子郵件驗證的郵件識別為合法。

案例：SPF 記錄或 DKIM 簽章中的網域不符合 From 位址中的網域。

結果：訊息可能會使複合驗證失敗。儘管複合驗證失敗，但如果其他評定未指出可疑性質，仍可能允許訊息：

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

案例：fabrikam.com 網域沒有SPF、DKIM或 DMARC 記錄。

結果：來自 fabrikam.com 網域中寄件者的訊息可能會使複合驗證失敗：

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 網域具有SPF記錄，且沒有 DKIM 記錄。 MAIL FROM 和 From 位址中的網域相符。

結果：訊息可以傳遞複合驗證，因為傳遞 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 簽署訊息的網域符合 [寄件者] 位址中的網域。

結果：訊息可以傳遞複合驗證，因為 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 簽章中的網域不符合 From 位址中的網域。

結果：訊息可能會使複合驗證失敗：

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 客戶可以使用下列方法，允許寄件者收到識別為詐騙或驗證失敗的訊息：

設定網域的SPF、DKIM和 DMARC 記錄：使用網域註冊機構或 DNS 裝載服務所提供的設定資訊。另外還有一些第三方公司專門用來協助設定電子郵件驗證記錄。

許多公司不會發佈 SPF 記錄，因為他們不知道其網域中所有郵件的電子郵件來源。
1. 首先，發佈SPF記錄，其中包含您知道的所有電子郵件來源 (特別是公司流量位於) 的位置，並使用強制規則值「軟性失敗」 (~all) 。例如：
```
fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"
```
  如果您建立此SPF記錄，Microsoft 365會將來自公司基礎結構的輸入電子郵件視為已驗證，但如果無法進行復合驗證，則來自無法辨識來源的電子郵件仍可能標示為詐騙。不過，此行為對於網域中所有寄件者的電子郵件仍會受到改善，Microsoft 365 標示為詐騙。一般而言，當SPF設定為虛失敗強制執行規則時，目的地電子郵件系統會接受來自無法辨識來源之網域中發件人的訊息。
2. 探索並包含訊息的更多電子郵件來源。例如：
  - 內部部署電子郵件伺服器。
  - 軟體即服務 (SaaS) 提供者傳送的電子郵件。
  - 從雲端主控服務 (Microsoft Azure、GoDaddy、Rackspace、Amazon Web Services 等等) 傳送的電子郵件。
  識別網域的所有電子郵件來源之後，您可以更新 SPF 記錄，以使用強制規則值「硬性失敗」 (-all) 。
3. 設定 DKIM 以數位簽署訊息。
4. 設定 DMARC 以驗證 MAIL FROM 和 From 位址中的網域是否相符、指定如何處理 DMARC 檢查失敗 (拒絕或隔離) 的郵件，以及識別要監視 DMARC 結果的 Reporting Services。
5. 如果您使用大量寄件者代表您傳送電子郵件，請確認From位址中的網域符合通過SPF或 DMARC 的網域。
您載入網域的電子郵件，或提供可傳送電子郵件的裝載基礎結構：
- 請確定您的客戶有說明如何為其網域設定SPF的檔。
- 請考慮 DKIM 簽署 DKIM 輸出郵件，即使客戶未在其網域中明確設定 DKIM， (使用預設網域) 進行簽署。您甚至可以使用公司網域和客戶網域 (的 DKIM 簽章來按兩下電子郵件) 。
即使您驗證來自平台的電子郵件，也不保證會傳遞至Microsoft。但是，電子郵件驗證可確保Microsoft不會因為未通過驗證而自動從客戶網域傳送垃圾郵件。

共用方式為