InfraAcademy Blog

複合機やサーバーの通知メールが、年明けに届かなくなるかもしれません。Exchange OnlineのSMTP AUTH基本認証が12月末に既定で無効へ

公開日: 2026-10-13 更新日: 2026-10-13 著者: ryu | #セキュリティ #Microsoft 365 #Exchange Online

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

みなさんの会社の複合機は、スキャンした書類をどうやってメールで送っているか知っていますか？

サーバーの監視ツールやcronの通知、業務システムのパスワード再設定メールも同じです。送信先のメールサーバーがMicrosoft 365のExchange Onlineなら、今年の年末に一度設定を見ておいたほうがいいかもしれません。

Exchange Onlineでは、SMTP AUTHの基本認証（ユーザー名とパスワードだけでのログイン）が、2026年12月末から既定で無効になる予定です。

この記事では、何が変わるのか、どんな機器やサーバーが影響を受けやすいのか、そして移行先をどう選べばいいのかを順番に見ていきます。

SMTP AUTHの基本認証とは？¶

まずは言葉の整理からです。

SMTPは、メールを送るときに使うプロトコルです。SMTPそのものの仕組みは、SMTPを扱った基本情報技術者試験の過去問解説でも紹介しています。

SMTP AUTHは、メールを送る前に「この送信者は誰か」をサーバーに証明するための仕組みです。Exchange Onlineでは、Microsoftのドキュメントでクライアント送信（Client Submission）と呼ばれています。

SMTP AUTH（クライアント送信）は、アプリや機器が smtp.office365.com のポート587にTLSで接続し、メールボックスのアカウントでサインインしてからメールを送る方式です。

このときの「サインインのしかた」が2種類あります。

認証のしかた	中身	今回の変更
基本認証（Basic認証）	ユーザー名とパスワードをそのまま送る	2026年12月末から既定で無効
OAuth（先進認証）	Microsoft Entra IDからトークンをもらって送る	引き続き使える

基本認証は設定が簡単なので、古い機器や手作りのスクリプトほどこちらを使っています。

ただ、パスワードが漏れればそのまま悪用されますし、多要素認証もかけられません。Microsoftは数年かけて、Exchange Onlineから基本認証を外してきました。今回のSMTP AUTHは、その最後に残っていた部分です。

ちなみに、Apacheの Basic認証の設定手順で出てくる「Basic認証」も、ユーザー名とパスワードをそのまま送るという点では同じ考え方です。

いつ、何が変わるの？¶

この件は、予定が何度か変わっています。古い情報のまま判断しないように、流れを整理しておきます。

予定の変わり方¶

Microsoftが最初にSMTP AUTHの基本認証の廃止を発表したのは、2024年4月です。

当初は2025年9月の廃止を目指していましたが、その後、2026年3月1日から拒否を始めて、4月30日に100%拒否するという予定に変わりました。

ところが、2026年1月27日の更新で、この予定はもう一度見直されました。現在の予定は次のとおりです。

時期	内容
2026年12月まで	これまでどおり。基本認証の動きは変わらない
2026年12月末	既存のテナントでも、SMTP AUTHの基本認証が既定で無効になる。管理者が必要なら再び有効にできる
2026年12月末以降に作られたテナント	最初から基本認証は使えない。OAuthが前提
2027年後半	完全に廃止する日付が発表される予定

ネット上には、いまでも「2026年4月30日に終了」と書いた記事が残っています。これは1月の更新より前の情報なので、計画を立てるときは使わないようにしましょう。

「既定で無効」は、何もしないと止まるということ¶

2026年12月末の変更は「完全に廃止」ではありません。管理者が設定を戻せば、しばらくは基本認証を使い続けられます。

それでも、何も準備していない現場では、年末年始の休み明けに次のようなことが起きる可能性があります。

複合機でスキャンしたPDFがメールで届かない
監視ツールのアラートメールが来ない
業務システムの通知メールが送られていない

とくに監視の通知が止まるのは怖いところです。障害が起きていても気づけず、「メールが来ないから平和だ」と思い込んでしまいます。

基本認証で送ろうとしたクライアントには、次のようなエラーが返るとされています。

550 5.7.30 Basic authentication is not supported for Client Submission.

ログでこのエラーを見かけたら、今回の変更の影響を疑ってください。

どこで基本認証を使っているかを洗い出す¶

まずやるべきことは、社内でSMTP AUTHの基本認証を使っている機器やサーバーを見つけることです。

思いつくものを並べると、だいたい次のあたりになります。

送信元	よくある使い方	確認する場所
複合機・スキャナー	スキャンtoメール	機器の管理画面のSMTP設定
Linuxサーバー	Postfixのリレー、cronの通知	`/etc/postfix/main.cf` など
監視ツール	Zabbixなどのアラート通知	ツールのメディア（送信方法）設定
業務アプリ	自社開発のシステムからの通知	アプリの設定ファイルや環境変数
スクリプト	PowerShellやPythonでのメール送信	ジョブの中身

共通する目印は、送信先が smtp.office365.com のポート587で、ユーザー名とパスワードを設定していることです。

Linuxサーバーで確認する¶

Linuxサーバーからのメール送信では、Postfixを使って外のSMTPサーバーへ中継（リレー）していることがよくあります。Postfixの基本的な構築は、postfixの構築方法で解説しています。

Exchange Onlineへリレーしているかは、次のように確認できます。

# 中継先のSMTPサーバーを確認する
postconf relayhost

# SASL（ユーザー名とパスワード）で認証しているか
postconf smtp_sasl_auth_enable smtp_sasl_password_maps

# 設定ファイルに smtp.office365.com が書かれていないか探す
sudo grep -rn "smtp.office365.com" /etc/postfix/ /etc/ 2>/dev/null

relayhost が [smtp.office365.com]:587 で、smtp_sasl_auth_enable = yes になっていれば、基本認証で送っている可能性が高いです。

すでにエラーが出ていないかは、メールのログで確認します。

# systemd環境でPostfixのログを見る
sudo journalctl -u postfix --since "7 days ago" | grep "5.7.30"

# ログをファイルに出しているディストリビューションの場合
sudo grep "5.7.30" /var/log/maillog /var/log/mail.log 2>/dev/null

cronのジョブ結果をメールで受け取っている場合も、この経路を通っていることがあります。cronの通知の出し方は cronとsystemd timerの使い分けの記事も参考にしてください。

Exchange Online側で確認する¶

Microsoft 365の管理者であれば、Exchange Online PowerShellで設定を確認できます。

SMTP AUTHの設定は、組織全体の設定と、メールボックスごとの設定の2段階になっています。メールボックスごとの設定のほうが優先されます。

# 組織全体の設定（True なら組織としては無効）
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

# メールボックスごとの設定（空なら組織の設定に従う）
Get-CASMailbox -Identity scanner@example.com | Format-List SmtpClientAuthenticationDisabled

メールボックスの値は $true（無効）、$false（有効）、$null（組織の設定に従う）の3つです。組織全体では無効にしていても、複合機用のアカウントだけ $false にして使っている、という運用はよくあります。

洗い出しのときは、組織全体の設定だけを見て安心しないことが大事です。メールボックスごとに有効にしているアカウントが、まさに今回の影響を受ける候補になります。

移行先はどう選べばいいの？¶

基本認証をやめるときの選択肢は、大きく分けて4つあります。どれが向いているかは、送信先が社内だけか、社外にも送るか、そして機器がOAuthに対応しているかで変わります。

方法	社外へ送れるか	認証	向いているケース
SMTP AUTH＋OAuth	送れる	OAuthトークン	OAuthに対応した新しい機器やアプリ
直接送信（Direct Send）	送れない（自社ドメイン宛てのみ）	なし	社内宛てだけでよい複合機
SMTPリレー（コネクタ）	送れる	固定のグローバルIPか証明書	固定IPの拠点から、まとめて送りたい場合
High Volume Email（HVE）	社内宛てが中心	基本認証も当面可	社内向けの大量送信

それぞれの特徴を見ていきます。

SMTP AUTHのまま、OAuthに切り替える¶

いちばん素直なのは、機器やアプリの設定をOAuthに切り替える方法です。

ただし、機器側がOAuthに対応していないと使えません。複合機なら、メーカーのファームウェア更新でOAuthに対応しているかを確認してください。古い機種だと対応予定がないこともあります。

自社開発のアプリなら、Microsoft Entra IDにアプリを登録して、トークンを取得する処理を追加することになります。

直接送信（Direct Send）¶

直接送信は、認証せずに、自社ドメインのMXレコードが指すExchange Onlineの受信口へ、ポート25で直接メールを渡す方法です。MXレコードについては、DNSの基本の記事でも触れています。

認証がいらないので、OAuthに対応していない古い複合機でも使えます。そのかわり、届けられるのは自社のドメイン宛てだけです。社外の取引先にスキャンを送るような使い方には向きません。

SMTPリレー（コネクタ）¶

SMTPリレーは、Exchange Onlineに「この固定IPからのメールは中継してよい」という受信コネクタを作って送る方法です。

社外にも送れて、機器ごとにアカウントを持たなくてよいのが利点です。一方で、拠点に固定のグローバルIPが必要で、SPFレコードの設定なども含めて準備がいちばん多くなります。

High Volume Email（HVE）¶

HVEは、社内向けの大量メールを送るためにMicrosoftが用意した仕組みです。2026年3月に一般提供が始まり、基本認証も2028年9月まで使えると案内されています。

ただし、送れるのは基本的に社内の受信者です。社外へ送る用途の置き換えにはなりません。「とりあえずHVEに逃がせば全部解決」とは考えないほうがいいでしょう。

年末までの進め方¶

ここまでの内容を、作業の順番にまとめておきます。

時期の目安	やること
10月〜11月	送信元の洗い出し。機器・サーバー・アプリごとに、送信先が社内だけか社外もあるかを書き出す
11月	機器ごとに移行先を決める。OAuth対応の有無をメーカーに確認する
11月〜12月中旬	検証環境や1台目で切り替えて、実際にメールが届くか確認する
12月中旬まで	本番の切り替え。どうしても間に合わない機器は一覧にして、再有効化の判断を決めておく

ポイントは、「間に合わなかったら管理者が戻せる」ことを、最初から予定に組み込まないことです。戻せるのはあくまで一時的な措置で、2027年後半には完全廃止の日付が発表される予定です。

もう1つ大事なのは、切り替えたあとに通知が本当に届くかを確かめることです。監視ツールならテスト通知を送り、cronならわざと失敗するジョブを1回動かしてみます。

# Postfixの経路で、テストメールを1通送ってみる
echo "test from $(hostname)" | mail -s "SMTP test" admin@example.com

# 送信キューに詰まっていないか確認する
mailq

キューにメールが残り続けていたら、どこかで止まっています。ログを見て、エラーコードを確認しましょう。

インフラエンジニアとして押さえておきたいこと¶

今回の話は、Microsoft 365の管理者だけの問題に見えるかもしれません。

でも実際に影響を受けるのは、Linuxサーバーの通知、監視ツール、ネットワーク機器のアラートなど、インフラエンジニアが面倒を見ている仕組みです。「メールは情報システム部門の担当だから」と思っていると、自分のサーバーの通知が止まっていた、ということになりかねません。

また、パスワードだけでの認証をやめる流れは、メールに限った話ではありません。社内ネットワークの中だから安全、という考え方を見直すゼロトラストの流れとも重なっています。

メールの送信経路を説明できるようになるには、SMTPやDNSに加えて、Linuxのサービスやログの見方が欠かせません。InfraAcademyの Linuxロードマップでは、コマンドの基本からサービスの構築、ログの確認までを順番に学べます。今回のような変更が来たときに、自分で影響範囲を調べられる力を一緒につけていきましょう。