複合機数十台を拠点間に配置し、スキャンtoメール機能でスキャンした書類を担当者へ自動送信している数千人規模の企業の情シス担当者にとって、2026年末は見過ごせない期限になる。基幹システムの帳票送信や監視アラートの自動メールでExchange Online（Microsoft 365のクラウド版メールサービス）宛にSMTP AUTH（SMTP認証、ユーザー名とパスワードで送信元を確認する仕組み）を使っている場合も同様だ。MicrosoftはSMTP AUTHのうちBasic認証（パスワードをそのまま送る旧来の認証方式）による接続を、2026年12月末に既存テナントでも既定で無効化すると発表した[1]。無効化後も管理者は再有効化できるため即座に送信が止まるわけではないが、対応を先送りするほど棚卸し範囲が広がる。本稿は移行計画の判断材料を整理する。
予備知識
- SMTP AUTH（SMTP認証）: メールを送信する際、サーバーが送信元をユーザー名とパスワードなどで確認する仕組み。複合機のスキャンtoメールや業務システムの自動送信メールで使われる。
- Basic認証: ユーザー名とパスワードをそのまま送信して認証する古い方式。パスワードが漏れると、そのまま第三者に悪用されてしまう弱点がある。
- OAuth 2.0: パスワードの代わりに有効期限付きのアクセストークンを使う認証の仕組み。多要素認証や条件付きアクセスと組み合わせやすい。
- クライアント送信（Client Submission）: メールクライアントやアプリがSMTPサーバーへ直接メールを送信する処理。POP/IMAPでの受信と対になり、送信だけSMTP AUTHを使う構成が多い。
ユーザー管理やメール設定を含むOffice 365/Microsoft 365の運用管理をGUIとPowerShellの両面から押さえたい担当者向け（2018年刊）
2026年12月末、既存テナントでもSMTP AUTHのBasic認証が既定無効化される
この廃止計画は2度延期されている。当初は2025年9月の廃止が予定され、次に「2026年3月1日から段階的に拒否を始め、4月30日に100%拒否」へ改められた[4]。2026年1月27日にMicrosoftは再度これを見直し、現在の計画を告知した[1]。
現在の計画は4段階である。2026年12月までは挙動を変えない。2026年12月末に既存テナントで既定無効化されるが、管理者は必要なら有効化し直せる。2026年12月より後に作成された新規テナントでは既定で利用できず、OAuthが唯一のサポート方式になる。そして完全廃止日は2027年後半に改めて告知される[1]。
つまり期日を過ぎた瞬間に全社のメール送信が止まるわけではない[1][2]。ただしこれは猶予であって撤回ではなく、告知のたびに条件が変わっている点には注意がいる。2024年4月の旧告知[4]は「再有効化はできない（You will not be able to do this）」と明記していたが、現在の告知[1]では再有効化が可能とされている。 古い記事や社内資料を根拠に判断すると逆の結論になる。
Basic認証からOAuth 2.0への移行がなぜ必要かを、仕組みの原理から理解したい担当者向け
複合機のスキャンtoメールと基幹システムが直撃する理由
既定無効化の影響は個人のメールクライアントよりも、業務システムや機器の自動送信機能に集中する。対象は複合機のスキャンtoメール機能、基幹システムからの帳票送信、監視システムのアラートメールなどだ[2][3]。導入時に設定して以降触られていないケースが多く、担当者交代後は変更対象と認識されないことがある。
| システム・機器 | SMTP AUTH使用例 | 対応要否の目安 |
|---|---|---|
| 複合機（スキャンtoメール） | AD連携でExchange宛に自動送信 | OAuth対応ファームウェアの有無を確認 |
| 基幹システム・帳票出力 | 請求書・納品書を添付で自動送信 | 送信モジュールのOAuth対応を開発元・SIerに確認 |
| 監視・アラートシステム | 障害検知メールをSMTP経由で送信 | 高ボリュームメール等の代替手段を検討 |
| POP/IMAPクライアント | 受信はPOP/IMAP、送信のみSMTP AUTH | モダン認証対応クライアントへ移行 |
複合機のスキャン送信連携や会議室予約システムなど、Exchange Web Services（EWS、旧来のメール連携API）経由でメール機能を呼び出す社内システムを何年も運用してきた、数千人規模の企業の情報システム部門にとって、2026[…]
無効化後も止めない方法——管理者の再有効化とOAuth移行の分岐
既定無効化後、対応が間に合わない場合、管理者はテナント全体または特定のメールボックス単位でSMTP AUTHを再有効化できる[2]。テナント全体はSet-TransportConfig -SmtpClientAuthenticationDisabled $falseで変更でき、状態はGet-TransportConfig | Format-List SmtpClientAuthenticationDisabledで確認する[2]。特定のメールボックスだけ例外にする場合はSet-CASMailbox -Identity <対象アドレス> -SmtpClientAuthenticationDisabled $falseを使い、メールボックス単位の設定を優先させる[2]。再有効化は暫定措置で、2027年後半に告知される完全廃止の時点では通用しなくなる[1]。
| 項目 | Basic認証（従来） | OAuth 2.0 |
|---|---|---|
| 認証情報 | ユーザー名＋パスワードを毎回送信 | 有効期限付きアクセストークン |
| 漏えい時のリスク | パスワードがそのまま悪用される | トークン単位で失効・制限が可能 |
| 多要素認証との併用 | 事実上困難 | 対応しやすい |
| 2026年12月末以降の扱い | 既定無効・管理者が再有効化可能 | 既定で利用可能 |
| 2027年1月以降の新規テナント | 提供されない | 唯一の選択肢 |
数千人規模でEntra ID（旧Azure AD）とオンプレADを併用し、年次の内部監査があるような日本企業のID基盤担当者は、SMSや音声通話によるMFA（多要素認証）を、まだ主要な認証手段として使い続けている場合が多い。Microso[…]
日本企業のレガシー複合機・オンプレ業務システムほど対応が遅れやすい理由
この問題の律速は自社ではなく機器メーカーにある。Office 365 for IT Prosは「コードを更新できるのはデバイスベンダーだけであり、顧客が問い合わせても要領を得ない反応が返ってくることが多い」と書いている[3]。OAuth対応はファームウェアの機能追加であって設定変更ではないため、自社の判断だけでは動かせない。
したがって最初にやるべきは、SIerへの一般的な問い合わせではなく、メーカーが公開している機種別の対応可否を引くことである。たとえばキヤノンはiR-ADV／imageFORCEについて、OAuth 2.0でExchange Online（およびGoogle Workspace）へ送信する手順と対応機種一覧を公開している[5]。同社の資料はOAuth 2.0を設定するとSMTP認証が自動的にOFFへ切り替わることまで明記しており、切替時の挙動まで機種単位で確認できる。公開の粒度はメーカーによって差があり、機種一覧まで出している例もあれば、個別問い合わせに委ねている例もある。
そのうえで日本企業固有の制約が乗る。複合機や基幹システムは7〜10年単位の長期リース・保守契約で使われ、設定は導入時のまま放置されがちだ。ファームウェア更新が年間保守契約に含まれない場合、OAuth対応は追加見積もりの対象になり、稟議と予算化のサイクルを挟む。既定無効化は12月末だが、予算編成は4月起点の年度単位が多く、期中の追加予算化には別途決裁が必要になりやすい。
IT部門の判断は、今期中に「メーカー公開資料での対応可否」と「自機の型番・ファームウェア版数」を突き合わせること。対応機種であればファームウェア更新の可否と費用、非対応機種であれば代替経路（HVE・ハイブリッド中継・SMTP中継）か機器更改かの判断に移る。決裁側の判断は、非対応機が出た場合に備えて期中の追加予算化を前提にした稟議ルートを用意しておくことだ。
| 観点 | 海外クラウドネイティブ組織 | 日本企業（レガシー環境） |
|---|---|---|
| 更新サイクル | 数年で入替・SaaS化が進みやすい | 7〜10年のリース・保守契約が一般的 |
| OAuth対応の扱い | 標準機能として提供されやすい | SIerとの追加契約対象になりやすい |
| 予算化のタイミング | 必要時に随時 | 年度予算（4月起点）に縛られやすい |
| 意思決定の起点 | 現場が直接対応 | 稟議・承認フローを経る |
※この表は公開された統計ではなく、筆者が実務で見てきた典型例の整理である。
まとめ
SMTP AUTH Basic認証は2026年12月末に既存テナントでも既定無効化されるが、管理者による再有効化という猶予がある一方、2027年後半には完全廃止日が告知される見通しだ。複合機のスキャンtoメールや基幹システムの自動送信は放置されやすく、日本企業ではSIerとの保守契約と年度予算のサイクルが対応を遅らせる。IT部門は今期中に対象機器の棚卸しとOAuth対応可否の確認に着手し、決裁側は期中の追加予算化を前提にした稟議ルートを準備しておくべきだ。再有効化は時間稼ぎであり、移行計画の先送り理由にはならない。
よくある質問（FAQ）
Q1. 複合機がSMTP AUTHを使っているか確認する方法は？
複合機のメール設定画面で送信方式を確認する。Exchange Online側はGet-CASMailboxで対象メールボックスのSmtpClientAuthenticationDisabled設定を確認し、送信履歴と突き合わせるとよい[2]。
Q2. 12月末を過ぎたら即座に送信が止まりますか？
既存テナントは既定無効化されるが、管理者がSet-TransportConfig等で再有効化すれば継続できる[1][2]。ただし2027年後半に告知される完全廃止の時点では有効ではなくなる[1]。
Q3. OAuth対応が難しい古い複合機はどうすればいいですか？
Microsoftは代替として、内部宛送信限定の高ボリュームメール（HVE）、オンプレExchange Serverを経由するハイブリッド中継、Azure Communication Services Emailを挙げている[4]。これらに当てはまらない場合、外部のSMTP中継サービスを挟む選択肢もある[3]。
出典
[1] Microsoft Tech Community, “Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline”（2026年1月27日・現行の告知） https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835[2] Microsoft Learn, “Enable or disable SMTP AUTH in Exchange Online” https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission
[3] Office 365 for IT Pros, “SMTP AUTH Client Submission Retirement Delayed” https://office365itpros.com/2026/01/29/smtp-auth-basic-retirement/
[4] Microsoft Tech Community, “Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)”（2024年4月15日・[1]により改訂された旧告知） https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750
[5] キヤノン, “【iR-ADV】【imageFORCE】OAuth2.0を利用してクラウドメールサーバーを使用する” https://faq.canon.jp/app/answers/detail/a_id/104800
