EOP 如何驗證發件者位址以防止網路釣魚

提示

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

網路釣魚攻擊是任何電子郵件組織的持續威脅。 除了使用 偽造的 (偽造) 寄件者電子郵件地址，攻擊者通常會使用 [寄件者] 位址中違反因特網標準的值。 為了協助防止這種類型的網路釣魚，Exchange Online Protection (EOP) 和 Outlook.com 要求輸入訊息包含符合 RFC 標準的寄件者位址，如本文所述。

  • 如果您如本文所述，定期收到來自格式不正確的組織電子郵件，請鼓勵這些組織更新其電子郵件伺服器，以符合新式安全性標準。

  • [代理傳送者] 和 [郵件] 清單 (使用的相關 [寄件者] 字段) 不受這些需求影響。 如需詳細資訊，請參閱下列部落格文章： 當我們參考電子郵件的「寄件者」時，我們代表什麼意思？。

電子郵件訊息標準概觀

標準 SMTP 電子郵件由「郵件信封」(Message Envelope) 和郵件內容組成。 訊息信封包含在 SMTP 伺服器之間傳輸和傳遞訊息所需的資訊。 郵件內容包含統稱為 (「郵件標頭」) 的郵件標頭欄位和郵件內容。 訊息信封會在 RFC 5321 中描述，而訊息標頭則會在 RFC 5322 中描述。 收件者永遠不會看到實際的郵件信封，因為它是由訊息傳輸程式所產生，而且實際上不是郵件的一部分。

  • MAIL FROM 位址 (也稱為 5321.MailFrom 位址、P1 發件者或信封發件者) 是郵件 SMTP 傳輸中使用的電子郵件位址。 此電子郵件位址通常會記錄在郵件標頭 (的 Return-Path 標頭欄位中，不過發件者可以指定不同的 Return-Path 電子郵件地址) 。

  • 寄件者位址 (也稱為 5322.From 位址或 P2 發件者) 是 [寄 件者] 標頭字段中的電子郵件位址，而 是電子郵件用戶端中顯示的寄件者電子郵件位址。 From 位址是本文中需求的重點。

From 位址會在數個 RFC (中詳細定義，例如 RFC 5322 區段 3.2.3、3.4 和 3.4.1， 以及 RFC 3696) 。 在尋址方面有許多變化，以及被視為有效或無效的內容。 若要保持簡單，建議您使用下列格式和定義：

From: "Display Name" <EmailAddress>

  • 顯示名稱：描述電子郵件地址擁有者的選擇性片語。

    • 建議您一律以雙引弧括住顯示名稱 ( ) 如所示。 如果顯示名稱包含逗號，您 必須 以每個 RFC 5322 的雙引號括住字串。
    • 如果 From 位址包含顯示名稱，則 EmailAddress 值必須以角括弧括住 (<>) ，如下所示。
    • Microsoft 強烈建議您在顯示名稱和電子郵件地址之間插入空格。

  • EmailAddress：電子郵件位址使用 格式 local-part@domain：

    • local-part：字串，識別與地址相關聯的信箱。 此值在網域內是唯一的。 通常會使用信箱擁有者的用戶名稱或 GUID。
    • domain：完整功能變數名稱 (裝載電子郵件地址本機部分所識別之信箱的電子郵件伺服器 FQDN) 。

    也：

    • 僅限一個電子郵件位址。
    • 建議您不要以空格分隔角括弧。
    • 請勿在電子郵件地址之後包含文字。

從位址取得良好和不良的範例

下表包含有效 From 位址的範例：

地址 Comments
From: sender@contoso.com 確定
From: <sender@contoso.com> 確定
From: < sender@contoso.com > 確定，但不建議使用，因為角括弧和電子郵件地址之間有空格。
From: "Sender, Example" <sender.example@contoso.com> 確定
From: "Microsoft 365" <sender@contoso.com> 確定
From: Microsoft 365 <sender@contoso.com> 確定，但不建議使用，因為顯示名稱未以雙引弧括住。

下表包含無效的 From 位址範例：

地址 Comments
No From address 當訊息抵達 Microsoft 365 或 Outlook.com 但不含發件者位址時，我們會嘗試將 MAIL FROM 位址指派給發件者位址，以確保訊息可傳送。 目前，即使原始From位址是 From: <>，服務仍會接受這些訊息。
From: <firstname lastname@contoso.com> 電子郵件位址包含空格。
From: Microsoft 365 sender@contoso.com 顯示名稱存在，但電子郵件位址未以角括弧括住。
From: "Microsoft 365" <sender@contoso.com> (Sent by a process) 電子郵件地址後面的文字。
From: Sender, Example <sender.example@contoso.com> 顯示名稱包含逗號，但未以雙引弧括住。
From: "Microsoft 365 <sender@contoso.com>" 整個值不正確地以雙引號括住。
From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com 顯示名稱存在，但電子郵件位址未以角括弧括住。
From: Microsoft 365<sender@contoso.com> 顯示名稱與左角括弧之間沒有空格。
From: "Microsoft 365"<sender@contoso.com> 右雙引號和左角括弧之間沒有空格。

隱藏自訂網域的自動回復

您無法使用 值 From: <> 來隱藏自動回復。 相反地，您必須設定自定義網域的 Null MX 記錄 。 設定 Null MX 記錄之後，會自然隱藏 所有 回復，因為回應伺服器沒有要傳送訊息的已發佈位址。

針對 Null MX 記錄，選擇無法接收電子郵件的電子郵件網域。 例如，如果主域 contoso.com，您可以選擇 noreply.contoso.com。 此網域的 Null MX 記錄是由單一句點所組成。 例如：

noreply.contoso.com IN MX .

如需設定 MX 記錄的詳細資訊，請參閱在任何 Microsoft 365 的 DNS 主機提供者 Create DNS 記錄。

如需發佈 Null MX 的詳細資訊，請參閱 RFC 7505。

覆寫從地址強制執行

若要略過輸入電子郵件的寄件者位址需求，您可以使用IP允許清單 (連線篩選) 或郵件流程規則 (也稱為傳輸規則) 如 Microsoft 365 中 Create 安全發件人清單中所述。 Outlook.com 不允許任何類型的覆寫，即使透過支援要求也一樣。

您無法覆寫從 Microsoft 365 或 Outlook.com 傳送之輸出電子郵件的寄件者位址需求。

在 Microsoft 365 中防止和防範網路犯罪的其他方式

如需如何加強貴組織防範網路釣魚、垃圾郵件、數據外洩和其他威脅的詳細資訊，請參閱保護 商務用 Microsoft 365 方案的最佳做法。