SMTP AUTH 基本身份驗證退役：找出所有發信設備

一句話結論： 根據 Exchange 團隊 2026 年 1 月 27 日公佈、1 月 29 日最後修訂（3.0 版）的最新時間表，SMTP AUTH 基本身份驗證在 2026 年 12 月之前照常可用；12 月底起，現有租戶預設關閉（管理員仍可重新開啓）；最終移除日期，微軟表示會在 2027 年下半年公佈。未來八個星期最應該做的，是列出所有仍以帳戶密碼發信的打印機、掃描器和應用程式，並逐一換成 OAuth、連接器中繼或其他發信方式。

SMTP AUTH 基本身份驗證退役屬於那種平日沒人留意、直到某天早上多功能一體機「掃描到電郵」突然失靈才被發現的變化。Exchange Online 早在 2022 至 2023 年間已停止 Outlook、ActiveSync、POP、IMAP 和遠程 PowerShell 的基本身份驗證。SMTP AUTH 客戶端提交，即掃描器、業務系統和舊式網站經 smtp.office365.com 發信所用的協議，因為太多辦公室設備依賴它，被留到最後。

本文講實際操作：截至 2026 年 10 月 31 日微軟究竟公佈了甚麼，怎樣在租戶內找出每一部仍以基本身份驗證發信的設備和每一個應用程式，以及怎樣逐一選擇替代方案。讀者是一月時會被問到「為甚麼掃描器發不到電郵」的那位同事。

退役的究竟是甚麼？何時生效？

現行時間表來自 Exchange 團隊 2026 年 1 月 27 日的網誌文章《Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline》；該文的版本紀錄顯示最後一次修訂為 2026 年 1 月 29 日（3.0 版），本文依據的是這一版本。這篇文章取代了 2024 年 4 月的原公告（訊息中心編號 MC786329）。原計劃是 2026 年 3 月 1 日開始拒絕基本身份驗證、4 月 30 日全面拒絕，這兩個日期已經作廢。如果供應商、討論區或舊文章仍引用它們，即表示對方依據的是已被取代的舊計劃。

截至 2026 年 10 月 31 日，我們在微軟官方渠道能找到的最新時間表仍是 1 月這篇（2026 年 1 月 29 日修訂版），分為三個階段：

現在至 2026 年 12 月。 沒有變化。凡是已經開啓的地方，SMTP AUTH 基本身份驗證照舊運作。
2026 年 12 月底。 現有租戶的 SMTP AUTH 基本身份驗證預設關閉。如果確實有設備來不及遷移，管理員仍可重新開啓。2026 年 12 月之後新建的租戶預設不提供基本身份驗證，支援的方式是 OAuth。
最終移除。 微軟尚未定出日期。Exchange 團隊的文章表示會在 2027 年下半年公佈；對應的訊息中心條目（MC786329）只寫了「2027 年」。

有兩點要說清楚，因為大部分誤解都出在這裡。

第一，微軟關閉的不是 SMTP，而是 SMTP AUTH 客戶端提交上的基本身份驗證。以 OAuth 2.0 權杖登入 smtp.office365.com 的設備會繼續運作；經連接器中繼或直接發送（Direct Send）發出的電郵亦不受影響，因為這兩種方式根本不用郵箱密碼登入。

第二，「預設關閉、但可重新開啓」是一段寬限期，不是解決方法。一月時把開關重新打開的租戶，只是把問題推遲到一個微軟尚未公佈的日子，該做的工作遲早要做。按本文任何日期做計劃之前，請再看一次 Exchange 團隊網誌，這個日期已經改過一次。

掃描器現在用得到，為甚麼還要理會？

因為這類故障出事前是無聲無息的。掃描器認證失敗不會自動開工單。同事按下「掃描到電郵」，電郵沒有到，過幾天才有人提起。如果同一個租戶內還有發送付款通知的財務系統、網站聯絡表格，或以電郵發警報的監察工具，它們也會一併停止，而且有些並不顯眼。

撇開微軟的時間表，這件事本身也有保安上的理由。基本身份驗證代表郵箱密碼存放在設備的設定頁面或應用程式的設定文件內，往往是一個共用的「scanner@」帳戶，密碼多年不變，而且因為設備無法回應驗證提示，被排除在多重身份驗證之外。這個帳戶就是條件訪問設計中一個長期存在的例外。我們的小型租戶條件訪問基線一文解釋了為甚麼阻擋舊式身份驗證應是小型租戶最先上線的策略之一，而每一個 SMTP AUTH 發信設備，都是當初沒有開啓這條策略的理由。

怎樣找出所有仍在使用 SMTP AUTH 基本身份驗證的設備和應用程式？

從三個方向入手，因為每個方向都能找到其他方向漏掉的東西。

先看 SMTP AUTH 客戶端報告

Exchange 管理中心有一份專門的報告。在新版 Exchange 管理中心，進入「報告」，再進入「郵件流」，打開「SMTP AUTH 客戶端報告」。它列出經 SMTP AUTH 發信的寄件地址、域名、所用身份驗證協議（基本或新式）、各 TLS 版本的流量比例和郵件數量。預設只顯示最近 7 日，請把日期範圍放寬：只在月底掃描的設備，在 7 日的範圍內是看不到的。

微軟在 Microsoft Learn 的《SMTP AUTH clients report in the new EAC in Exchange Online》一文中說明了這份報告。查看它需要文中列出的 Exchange 或保安讀取類角色之一，保安讀者（Security Reader）已經可以執行，不需要任何寫入權限。

再查電郵從哪裡發出

報告告訴您是哪個郵箱發了信，但不會告訴您是哪張枱上的哪部設備。要找到設備，請打開 Microsoft Entra 管理中心的登入記錄，把客戶端應用程式篩選為「Authenticated SMTP」。每條記錄都有帳戶、時間和來源 IP。辦公室的 IP 指向現場設備；雲端服務商網段內的 IP 通常是放在雲端的應用程式或網站；認不出的 IP 值得細看，因為 SMTP AUTH 也是攻擊者以盜取的憑證發信的途徑。

把結果整理成一張簡單的登記表，每個發信方一行：所用帳戶、是甚麼設備或應用程式、負責人、所在位置、發信頻率，以及收件人是內部還是外部。最後一欄決定了可以選哪種替代方案。

最後核對哪些郵箱獲准使用 SMTP AUTH

在 Exchange Online PowerShell 中，Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled 顯示組織層面的設定；Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } 列出個別開啓了 SMTP AUTH 的郵箱。微軟的《Enable or disable SMTP AUTH in Exchange Online》一文說明了優先次序：郵箱層面的 true 或 false 會凌駕組織設定，留空則跟隨組織設定。

把這份名單和登記表對照一下。開啓了但過去一個月沒有發過信的郵箱，是一個應該直接刪除的例外；發了信卻不在任何已知設備名單上的郵箱，就是最先要查的那一個。

有哪些替代方案？怎樣選擇？

微軟針對打印機、掃描器和業務應用程式的疑難排解文章列出了幾種主要方式。選哪一種，視乎設備能做甚麼，以及電郵要發到哪裡。

OAuth、連接器中繼還是直接發送？

使用 OAuth 2.0 的 SMTP AUTH。 設備或應用程式繼續經 587 埠向 smtp.office365.com 發信，只是改用權杖而非密碼登入。這是最乾淨的做法，也是微軟為新租戶指定的方式。限制在設備本身：不少 2020 年前後之前的掃描器沒有 OAuth 選項，有些要靠固件更新才有。請先查閱廠商最新的固件說明，不要想當然。
經連接器中繼。 在 Exchange Online 建立一個入站連接器，接受來自辦公室固定公網 IP 或證書的電郵，設備無需登入、直接發往您的 MX 端點。它可以發給外部收件人。前提是有固定 IP，而且該 IP 後面的所有設備都能中繼，所以最好配一條防火牆規則，只讓打印機所在網段訪問外部 25 埠。
直接發送（Direct Send）。 設備不經認證、不經連接器，直接發往您的 MX 端點。設定最簡單，但只能投遞給本機構內部的收件人。掃描到自己郵箱通常已經足夠；需要向客戶發電郵的系統則不適用。
業務應用程式改用 Microsoft Graph。 自行開發或第三方的業務應用程式可經 Microsoft Graph 的 sendMail 介面發信，使用帶 Mail.Send 權限的應用程式註冊，並把權限限定在它應該使用的郵箱。這樣便完全繞過 SMTP，也是大多數現代應用框架支援的方式。
Microsoft 365 大量電郵（High Volume Email）。 這是微軟為向內部收件人大量發信而設計的服務，例如發給全體員工的系統通知。使用前請在 Microsoft Learn 核對它目前的授權、限額和身份驗證方式，這項服務預覽期很長，條款其後亦有調整。

對於向客戶發送大量電郵的應用程式，第三方交易電郵服務也是合理選擇，但那是另一次採購，亦要另外維護一套 SPF、DKIM 和 DMARC 記錄。

一條簡單的判斷規則

設備支援 OAuth，就用 OAuth。不支援、而且只發給自己員工，就用直接發送。不支援、但必須發到外部，就用固定 IP 的連接器中繼。是您能控制的軟件，就遷移到 Graph。每一行的決定都寫進登記表，因為兩年後不會有人記得貨倉那部打印機為甚麼有自己的連接器。

怎樣趕在微軟之前自行關閉基本身份驗證？

按自己的日子關，好過按微軟的日子被關。計劃好的切換可以揀一個較清閒的星期，預先通知經常掃描的同事，並安排人在現場。

把登記表上每個發信方遷移到新方式，並確認測試電郵能送達內部，有需要時亦確認能送達外部。
以 Set-CASMailbox -Identity scanner@yourdomain.com -SmtpClientAuthenticationDisabled $true 刪除郵箱層面的例外，或設為 $null，讓它跟隨組織設定。
關閉組織層面的 SMTP AUTH。在 Exchange 管理中心，這是「郵件流設定」頁面上的「Turn off SMTP AUTH protocol for your organization」選項；在 PowerShell 中是 Set-TransportConfig -SmtpClientAuthenticationDisabled $true。
之後兩星期持續留意 SMTP AUTH 客戶端報告和 Authenticated SMTP 登入記錄。仍然出現的，就是漏掉的發信方。
確認沒有合法發信方之後，新增或確認阻擋舊式身份驗證的條件訪問策略，並把共用掃描帳戶移出所有 MFA 排除群組。

如果租戶啓用了保安預設值，SMTP AUTH 本來就是關閉的，現在能用的設備必定走其他方式。微軟亦指出，阻擋基本身份驗證的身份驗證政策，即使郵箱和組織設定都容許，也會令 SMTP AUTH 失效，這是「明明開了仍然不行」的常見原因。

Microsoft 365 保安審計在這方面檢查甚麼？

舊式身份驗證是我們 Microsoft 365 保安審計清單中的一個檢查範疇，而剩下的例外通常就藏在 SMTP AUTH 內。審計時，我們讀取組織和郵箱層面的 SMTP AUTH 設定、SMTP AUTH 客戶端報告和 Authenticated SMTP 登入記錄，再與條件訪問策略及其排除項逐一對照。報告逐一列出發信方、所用帳戶、該帳戶是否被排除在 MFA 之外，以及建議的替代方式，所以每項發現都附帶方案，而不只是一句警告。

Microsoft 365 保安審計示例報告（英文頁）以一間虛構公司展示這類發現的寫法：一項發現、背後的證據、處理所需的工作量，以及它屬於修正計劃的哪個階段。審計只讀、遙距交付，全域管理員授予只讀訪問後 5 至 7 個工作天出報告。價格按人數固定，10 位用戶以內 450 美元起，各級價格和完整範圍見 Microsoft 365 保安審計價格頁。

對英國的團隊來說，舊式身份驗證亦關係到 Cyber Essentials，它要求雲端服務啓用 MFA，對無法使用 MFA 的帳戶會追問。對澳洲及其他地區的團隊來說，這是大多數網絡保險投保問卷都會問的問題。兩種情況下，報告都是為了在這類對話中用作證據而設計，最終結論由評估方或保險公司自行決定。

如果您需要的是有人長期負責郵件流、連接器和過濾，而不是一次性覆核，Brocent 的託管電子郵件安全服務可以承擔這部分工作。