EOP 如何驗證發件者位址以防止網路釣魚
提示
您知道您可以免費試用 Office 365 方案 2 的 Microsoft Defender 全面偵測回應 功能嗎？ 使用 Microsoft Defender 入口網站試用中樞的 90 天 適用於 Office 365 的 Defender 試用版。 瞭解誰可以在 Try 適用於 Office 365 的 Microsoft 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 記錄的詳細資訊，請參閱在任何 DNS 主機提供者建立 DNS 記錄，Microsoft 365。
如需發佈 Null MX 的詳細資訊，請參閱 RFC 7505。
覆寫從地址強制執行
若要略過輸入電子郵件的寄件者位址需求，您可以使用IP允許清單 (連線篩選) 或郵件流程規則 (也稱為傳輸規則) 如在 Microsoft 365 中建立安全發件人清單中所述。 Outlook.com 不允許任何類型的覆寫，即使透過支援要求也一樣。
您無法覆寫從 Microsoft 365 或 Outlook.com 傳送之輸出電子郵件的寄件者位址需求。
在 Microsoft 365 中防止和防範網路犯罪的其他方式
如需如何加強貴組織防範網路釣魚、垃圾郵件、數據外洩和其他威脅的詳細資訊，請參閱保護 商務方案Microsoft 365 的最佳做法。