公式資料の最終確認日：2026 年 10 月 25 日。
廃止対象は SMTP AUTH 全体ですか？
対象は Exchange Online のクライアント SMTP 送信における基本認証です。SMTP AUTH は認証を伴う SMTP 送信の仕組みで、認証方式には基本認証のほかに OAuth があります。Microsoft の SMTP AUTH 解説も、この両方を区別しています。
したがって、「SMTP を使っている」という理由だけで、すべての機器を同じ移行対象にしないでください。まず、送信元が実際に使っている認証方式を調べます。ここでは Exchange Online を扱い、個人向け Outlook.com の接続復旧とは分けます。
廃止日程で区別すべき条件
社内の移行期限を決める際は、Microsoft の複合機・アプリ向け送信ガイドにある基本認証廃止の案内から、日程情報を確認してください。日付だけでなく、適用条件も記録します。
| 確認する項目 | 読み分けるポイント |
|---|---|
| 発表日・更新日 | 発表された日と、変更が適用される日を分けます |
| 旧予定・改定後の予定 | 旧予定をそのまま社内期限に転記しません |
| 既存・新規テナント | 自社に適用される条件を確認します |
| 既定で無効化 | 初期状態の変更と、管理者による再有効化の可否を分けます |
| 恒久的な廃止 | 管理者設定で利用できる期間とは別に確認します |
既定で無効になることと、完全に利用できなくなることは同じではありません。 再有効化できるかどうかは、その変更の適用条件で判断します。現在 SMTP AUTH を有効にできることを、基本認証を恒久的に使える根拠にはしないでください。
SMTP OAuth、リレー、Graph はどう違いますか？
| 接続方式 | 認証・接続の仕組み | 移行判断で確認すること |
|---|---|---|
| SMTP AUTH＋基本認証 | 基本認証によるクライアント SMTP 送信 | 今回の廃止対象として移行を計画します |
| SMTP AUTH＋OAuth | アクセストークンによる認証 | 機器・ライブラリの OAuth 対応を確認します |
| SMTP リレー | 受信コネクタによる認証 | 証明書または固定パブリック IP アドレスなどの条件を確認します |
| Microsoft Graph | SMTP ではなく API による送信 | アプリの実装と権限を確認します |
クライアント SMTP 送信には、ライセンスを持つ Microsoft 365 または Office 365 メールボックスが必要です。対して SMTP リレーは送信用のライセンス付きメールボックスを必要としませんが、接続条件があります。証明書を使えない場合は、他組織と共有していない固定パブリック IP アドレスが必要です。
Direct Send も別方式です。外部メールサーバーとして認証なしで直接送信しますが、Microsoft 365 を介したインターネット宛てのリレーには対応しません。外部宛ての通知がある場合は、この制約を先に確認してください。
自社の通知アプリや複合機の調査手順
- 送信元を列挙します。 通知アプリ、定期バッチ、複合機ごとに管理担当者を決めます。
- 接続情報を記録します。 接続先、ポート、認証方式、利用メールボックス、機器やライブラリの名称を残します。パスワードやトークンは棚卸し表に保存しません。
- 実際の認証方式を照合します。 機器の設定やアプリの実装を確認し、接続先やポートだけで基本認証と判定しないでください。
- 管理者設定を確認します。 組織とメールボックスの SMTP AUTH 設定に加え、セキュリティの既定値も確認します。
- 移行先と検証期限を決めます。 OAuth 対応、機器更新、別送信方式の検討に分類します。
Microsoft 365 管理センターでの確認経路は、公式手順では「Users」→「Active users」→対象ユーザー→「Mail」→「Manage email apps」です。「Authenticated SMTP」はチェックありで有効、なしで無効です。
このチェックは SMTP AUTH の許可設定です。アプリが基本認証と OAuth のどちらを使っているかは、送信元側でも確認します。
メールボックス単位の設定は組織設定より優先されます。SmtpClientAuthenticationDisabled の値を確認する場合は、次のように読みます。
| メールボックスの値 | 意味 |
|---|---|
False | SMTP AUTH が有効 |
True | SMTP AUTH が無効 |
| 空欄 | 組織設定を継承 |
また、セキュリティの既定値が有効な組織では SMTP AUTH は無効です。メールボックスの設定だけで判断しないでください。Microsoft は、組織全体では SMTP AUTH を無効にし、必要なメールボックスに限って有効にする運用を推奨しています。
移行先はどう選び、何をテストしますか？
SMTP クライアントを維持するなら、まず OAuth 対応を確認します。Microsoft の SMTP OAuth 手順では、アクセストークンの送信に SASL XOAUTH2 を使います。パスワードやポートを変えるだけの作業ではありません。
OAuth 非対応の複合機は、メーカーに対応機種や更新方法を確認します。SMTP リレーを検討する場合は、先に証明書や固定 IP アドレスの条件を満たせるかを調べてください。
アプリを改修できるなら Microsoft Graph も候補です。Graph の sendMail 仕様では、JSON または MIME でメッセージを送信します。職場・学校アカウントの委任アクセス許可とアプリケーションのアクセス許可には、Mail.Send が示されています。SMTP の接続設定だけでなく、API 呼び出しの実装が必要です。
切り替えは次の順序で進めます。
- 自社のテスト用メールボックスと送信先を用意します。
- 必要な権限と、管理者が許可する接続方式を確認します。
- 自分で管理するテスト用宛先へ送信します。
- 送信側の応答と、受信側のメッセージを照合します。
- 失敗時の時刻、応答、対象設定を記録し、送信元ごとに段階的に切り替えます。
Graph の 202 Accepted は要求の受付を示し、処理完了や配信完了を示しません。配信には Exchange Online の制限やスロットリングも適用されます。接続できた時点で検証を終えず、受信まで確認してください。
Mailera の Microsoft 接続はどう関係しますか？
Mailera の Microsoft 接続は、既存の Microsoft メールボックスに OAuth と Microsoft Graph で接続します。SMTP AUTH の基本認証を使う接続ではなく、アプリパスワードも使いません。
追加は Admin または Leader ロールで行います。
- 「メールボックス」から「メールボックスを追加」を開きます。
- 「Microsoftでサインイン」を選び、Microsoft 側で OAuth の同意を行います。
- メールボックス一覧で接続状態を確認し、用途に応じた送受信テストを行います。
権限や接続準備は、Microsoft 365 の Graph 接続チェックリストで整理できます。既存メールボックスを外部のアプリから利用する全体像は、既存メールサービスの接続ガイドも参照してください。
Mailera は既存メールボックスを接続する製品であり、新しいメールアドレスを作成しません。既存の複合機や SMTP アプリを自動で OAuth に移行する機能でもありません。一斉配信・マーケティング送信には対応せず、受信トレイへの配信も保証しません。
導入時は Mailera の機能範囲と セキュリティ情報を確認してください。アプリ側の実装には 開発者向け案内を使い、Microsoft 側の権限やポリシーも別途確認します。
よくある失敗と確認点
旧日程を社内期限として固定する。 Microsoft の該当ページで更新日と適用対象を確認し直し、社内の切り替え計画をその内容に合わせて見直します。
SMTP AUTH を有効にすれば移行不要と考える。 現在の許可設定と、サービス側の基本認証廃止は別です。
接続成功だけで完了とする。 認証、送信要求の受付、実際の受信を分けて確認します。エラーが出たら、応答を省略せずに記録し、認証方式と設定を照合してください。基本認証への切り戻しを、長期運用の前提にはしないでください。
