Exchange Online の SMTP AUTH 基本認証廃止：既定で無効になる前に複合機とアプリを洗い出す

要点： Exchange チームが 2026 年 1 月 27 日に公表し、1 月 29 日に最終改訂（バージョン 3.0）した最新のスケジュールでは、SMTP AUTH の基本認証は 2026 年 12 月まではこれまでどおり使え、12 月末に既存テナントで既定で無効になり（管理者は再度有効にできます）、最終的な廃止日は 2027 年後半に発表されるとされています。これからの 8 週間でやるべきことは、ユーザー名とパスワードでメールを送っている複合機、スキャナー、アプリケーションをすべて一覧にし、それぞれを OAuth、コネクタ経由のリレー、または別の送信経路に移すことです。

SMTP AUTH 基本認証の廃止は、ある朝複合機の「スキャン to メール」が動かなくなって初めて気づかれる、という種類の変更です。Exchange Online は 2022 年から 2023 年にかけて、Outlook、ActiveSync、POP、IMAP、リモート PowerShell の基本認証をすでに止めています。スキャナーや業務システム、古い Web サイトが smtp.office365.com 経由でメールを送るための SMTP AUTH クライアント送信は、依存しているオフィス機器があまりに多いため、最後まで残されていました。

本記事は実務向けの内容です。2026 年 10 月 31 日時点で Microsoft が実際に何を発表しているのか、テナント内で基本認証を使って送信している機器とアプリをどう見つけるのか、そしてそれぞれの移行先をどう選ぶのかを説明します。1 月に「スキャナーからメールが届かない」と聞かれることになる担当者のための記事です。

何が、いつ廃止されるのか？

現行のスケジュールは、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 日時点で、Microsoft の公式チャネルで確認できた最新のスケジュールは 1 月の記事（2026 年 1 月 29 日改訂版）です。内容は三段階に分かれています。

• 現在から 2026 年 12 月まで。 変更はありません。有効になっている環境では、SMTP AUTH の基本認証はこれまでどおり動作します。
• 2026 年 12 月末。 既存テナントで SMTP AUTH の基本認証が既定で無効になります。どうしても移行が間に合わない機器がある場合、管理者は再度有効にできます。2026 年 12 月以降に新規作成されるテナントでは既定で基本認証は利用できず、サポートされる方式は OAuth です。
• 最終的な廃止。 日付はまだ決まっていません。Exchange チームの記事は 2027 年後半に発表するとしており、対応するメッセージセンターの項目（MC786329）では「2027 年」とだけ記されています。

混乱のほとんどはこの 2 点から生じるため、正確に押さえておきます。

第一に、Microsoft が止めるのは SMTP そのものではなく、SMTP AUTH クライアント送信における基本認証です。OAuth 2.0 のトークンで smtp.office365.com にサインインする機器はそのまま動きます。コネクタ経由のリレーや Direct Send で送られるメールも影響を受けません。これらはそもそもメールボックスのパスワードでサインインしないからです。

第二に、「既定で無効、ただし再度有効にできる」は猶予期間であって解決策ではありません。1 月に設定を戻したテナントは、Microsoft がまだ発表していない日まで問題を先送りしただけで、同じ作業はいずれ必要になります。本記事の日付をもとに計画を立てる前に、Exchange チームのブログをもう一度確認してください。この日付はすでに一度変更されています。

今スキャナーが動いているなら、なぜ気にする必要があるのか？

この種の障害は、起きるまで静かだからです。スキャナーの認証が失敗しても、チケットが自動で起票されることはありません。社員が「スキャン to メール」を押し、メールが届かず、数日後に誰かが口にする。同じテナントに振込通知を送る経理システム、Web サイトの問い合わせフォーム、アラートをメールで送る監視ツールがあれば、それらも同時に止まり、中には目立たないものもあります。

Microsoft の日程とは別に、セキュリティ上の理由もあります。基本認証とは、メールボックスのパスワードが機器の設定画面やアプリケーションの設定ファイルに保存されているということです。多くの場合それは共有の「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 なら社内の機器、クラウド事業者のアドレス範囲ならクラウド上のアプリケーションや Web サイトであることが多く、見覚えのない IP は詳しく調べる価値があります。SMTP AUTH は、盗まれた資格情報で攻撃者がメールを送る経路でもあるからです。

結果を送信元ごとに 1 行の簡単な台帳にまとめます。使っているアカウント、機器またはアプリケーションの種類、担当者、設置場所、送信頻度、そして宛先が社内か社外か。最後の列で、選べる移行先が決まります。

最後に、SMTP AUTH を許可されているメールボックスを確認する

Exchange Online PowerShell では、Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled で組織全体の設定を確認できます。Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } を実行すると、個別に SMTP AUTH が有効にされたメールボックスが一覧になります。Microsoft の「Enable or disable SMTP AUTH in Exchange Online」が優先順位を説明しています。メールボックス単位の true または false は組織の設定より優先され、空欄であれば組織の設定に従います。

この一覧を台帳と突き合わせます。有効になっているのに過去 1 か月何も送っていないメールボックスは、単に削除すべき例外です。送信しているのに既知の機器リストのどこにも載っていないメールボックスは、最初に調べるべき対象です。

移行先にはどんな選択肢があり、どう選ぶか？

Microsoft のプリンター、スキャナー、業務アプリケーション向けトラブルシューティング記事に、主な経路が説明されています。どれが合うかは、機器に何ができるか、メールをどこへ届ける必要があるかで決まります。

OAuth、コネクタ リレー、Direct Send のどれにするか？

• OAuth 2.0 を使う SMTP AUTH。 機器やアプリケーションはこれまでどおりポート 587 で smtp.office365.com に送信し、パスワードの代わりにトークンでサインインします。最もすっきりした方法で、Microsoft が新しいテナントに案内している方式でもあります。制約は機器側にあり、2020 年ごろより前のスキャナーの多くには OAuth の選択肢がなく、ファームウェア更新で対応するものもあります。思い込まずに、メーカーの最新のファームウェア情報を確認してください。
• コネクタ経由のリレー。 Exchange Online に、オフィスの固定グローバル IP アドレスまたは証明書からのメールを受け付ける受信コネクタを作成し、機器はサインインせずに MX エンドポイントへ送信します。社外の宛先にも届けられます。固定 IP が前提で、その IP の背後にあるすべての機器がリレーできるようになるため、プリンターのセグメントだけが外部の 25 番ポートに出られるファイアウォール ルールと組み合わせるべきです。
• Direct Send。 機器は認証もコネクタも使わず、MX エンドポイントへ直接送信します。設定は最も簡単ですが、自組織内の宛先にしか届きません。自分のメールボックスへのスキャンならたいてい十分ですが、顧客にメールを送るシステムには使えません。
• アプリケーションは Microsoft Graph へ。 自社開発や業務用のアプリケーションは、Mail.Send 権限を持つアプリ登録を使い、Microsoft Graph の sendMail API で送信できます。権限は使うべきメールボックスに限定します。SMTP を完全に使わなくなる方法で、最近のアプリケーション フレームワークの多くが対応しています。
• Microsoft 365 の High Volume Email。 全社員向けのシステム通知など、社内宛ての大量送信向けに Microsoft が用意したサービスです。利用する前に、現在のライセンス、上限、認証方式を Microsoft Learn で確認してください。プレビュー期間が長く、その後条件が改定されています。

顧客向けに大量のメールを送るアプリケーションであれば、サードパーティのトランザクション メール サービスも妥当な選択肢です。ただし別の調達になり、SPF、DKIM、DMARC のレコードも別途管理する必要があります。

簡単な判断ルール

機器が OAuth に対応していれば OAuth。対応しておらず、社員宛てにしか送らないなら Direct Send。対応しておらず、社外に送る必要があるなら固定 IP からのコネクタ リレー。自社で管理できるソフトウェアなら Graph へ。各行の判断は台帳に書き残してください。2 年後には、倉庫のプリンターになぜ専用のコネクタがあるのか、誰も覚えていません。

Microsoft より先に、自分で基本認証を止めるには？

Microsoft の日程で止められるより、自分で決めた日に止めるほうが確実です。計画的な切り替えなら、落ち着いた週を選び、よくスキャンする社員に事前に知らせ、現地に担当者を置けます。

1. 台帳の送信元をそれぞれ新しい経路に移し、テスト メールが社内に、必要なら社外にも届くことを確認します。
2. Set-CASMailbox -Identity scanner@yourdomain.com -SmtpClientAuthenticationDisabled $true でメールボックス単位の例外を外すか、$null にして組織の設定に従わせます。
3. 組織全体で SMTP AUTH を無効にします。Exchange 管理センターでは「メール フローの設定」ページの「Turn off SMTP AUTH protocol for your organization」、PowerShell では Set-TransportConfig -SmtpClientAuthenticationDisabled $true です。
4. その後 2 週間、SMTP AUTH クライアント レポートと Authenticated SMTP のサインインを確認し続けます。まだ現れるものが、見落とした送信元です。
5. 正当な送信元が残っていないことを確認したら、レガシー認証をブロックする条件付きアクセス ポリシーを追加または確認し、共有のスキャナー用アカウントを MFA の除外グループから外します。

テナントでセキュリティの既定値が有効なら、SMTP AUTH はもともと無効で、今動いている機器はほかの経路を使っています。また Microsoft は、基本認証をブロックする認証ポリシーがあると、メールボックスや組織の設定で許可していても 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 のマネージドメールセキュリティで対応できます。

よくある質問

Microsoft は Exchange Online の SMTP を止めるのですか？

いいえ。廃止されるのは SMTP AUTH クライアント送信の基本認証だけです。OAuth を使う SMTP AUTH は引き続き使え、コネクタ リレーと Direct Send も動き続けます。これらはメールボックスのパスワードで認証しないためです。

2026 年 12 月末に何が起きますか？

Exchange チームの 2026 年 1 月の更新（1 月 27 日公開、1 月 29 日改訂）によれば、既存テナントで SMTP AUTH の基本認証が既定で無効になります。必要であれば管理者は再度有効にできます。最終的な廃止日は 2027 年後半に発表されるとされています。

1 月に基本認証を有効に戻せばよいのでは？

今のところは可能で、期限までに交換できない機器が 1 台あるなら妥当な短期策です。ただし計画ではありません。この設定はいずれ削除され、それまでの間、その機器が使うアカウントは MFA ポリシーの中でパスワードだけの例外であり続けます。

スキャナーが OAuth に対応しているかはどう確認しますか？

メーカーの最新ドキュメントとファームウェアのリリース ノートで、メール設定の項目に「OAuth」「先進認証」「Microsoft 365」といった記載があるかを確認します。機器の設定画面がユーザー名とパスワードしか求めないなら、ほぼ確実に基本認証を使っています。

スキャナーは社員宛てにしか送りません。最も簡単な対処は？

MX エンドポイントへの Direct Send です。アカウントもパスワードも不要です。届くのは組織内だけですが、スキャン to メールにはそれで足りることがほとんどです。

自社 Web サイトから送るメールも影響を受けますか？

サイトがメールボックスのユーザー名とパスワードで smtp.office365.com にサインインして送っているなら、影響を受けます。サイトのメール設定やプラグインの設定を確認してください。Microsoft Graph や専用のトランザクション メール サービスに移すほうが、通常はよい方法です。

スケジュールの変更はどこで発表されますか？

Exchange チームのブログと、Microsoft 365 管理センターのメッセージセンターです。Microsoft Learn の「Deprecation of Basic authentication in Exchange Online」ページも最新の発表を案内しています。

今週まず何をするか

SMTP AUTH クライアント レポートを開き、期間を直近 90 日にしてエクスポートしてください。その一覧を Authenticated SMTP のサインインと突き合わせれば、12 月末までにどれだけの作業があるかがわかります。社外の目でテナントを確認し、送信元ごとに移行先を付けた優先順位付きの一覧を受け取りたい場合は、コンサルタントにご相談ください。