---
title: "Exchange Online の SMTP AUTH 基本認証廃止：影響と移行の確認点"
description: "Exchange Online の SMTP AUTH 基本認証廃止に備え、複合機や通知アプリの認証方式、管理者設定、OAuth・SMTP リレー・Graph への移行判断を整理します。"
url: https://mailera.app/ja/blog/exchange-online-smtp-auth-retirement
published: 2026-10-25
updated: 2026-10-25
---

# Exchange Online の SMTP AUTH 基本認証廃止：影響と移行の確認点

通知アプリや複合機への影響は、SMTP を使っているかではなく、どの方式で認証しているかで判断します。SMTP OAuth、SMTP リレー、Microsoft Graph を分けて、確認箇所と移行先を整理します。

公式資料の最終確認日：2026 年 10 月 25 日。

## 廃止対象は SMTP AUTH 全体ですか？

対象は Exchange Online のクライアント SMTP 送信における基本認証です。SMTP AUTH は認証を伴う SMTP 送信の仕組みで、認証方式には基本認証のほかに OAuth があります。[Microsoft の SMTP AUTH 解説](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission)も、この両方を区別しています。

したがって、「SMTP を使っている」という理由だけで、すべての機器を同じ移行対象にしないでください。まず、送信元が実際に使っている認証方式を調べます。ここでは Exchange Online を扱い、個人向け Outlook.com の接続復旧とは分けます。

## 廃止日程で区別すべき条件

社内の移行期限を決める際は、[Microsoft の複合機・アプリ向け送信ガイド](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)にある基本認証廃止の案内から、日程情報を確認してください。日付だけでなく、適用条件も記録します。

| 確認する項目 | 読み分けるポイント |
| --- | --- |
| 発表日・更新日 | 発表された日と、変更が適用される日を分けます |
| 旧予定・改定後の予定 | 旧予定をそのまま社内期限に転記しません |
| 既存・新規テナント | 自社に適用される条件を確認します |
| 既定で無効化 | 初期状態の変更と、管理者による再有効化の可否を分けます |
| 恒久的な廃止 | 管理者設定で利用できる期間とは別に確認します |

**既定で無効になることと、完全に利用できなくなることは同じではありません。** 再有効化できるかどうかは、その変更の適用条件で判断します。現在 SMTP AUTH を有効にできることを、基本認証を恒久的に使える根拠にはしないでください。

## SMTP OAuth、リレー、Graph はどう違いますか？

| 接続方式 | 認証・接続の仕組み | 移行判断で確認すること |
| --- | --- | --- |
| SMTP AUTH＋基本認証 | 基本認証によるクライアント SMTP 送信 | 今回の廃止対象として移行を計画します |
| SMTP AUTH＋OAuth | アクセストークンによる認証 | 機器・ライブラリの OAuth 対応を確認します |
| SMTP リレー | 受信コネクタによる認証 | 証明書または固定パブリック IP アドレスなどの条件を確認します |
| Microsoft Graph | SMTP ではなく API による送信 | アプリの実装と権限を確認します |

![送信方式を基本認証、OAuth、SMTP リレー、Graph に分け、Mailera が Graph 接続を使うことを示す図](https://mailera.app/media/61537a653d60d078/exchange-online-smtp-auth-submission-options-ja-1200.jpg)
_同じメール送信でも、認証方式と接続条件は異なります。_

クライアント SMTP 送信には、ライセンスを持つ Microsoft 365 または Office 365 メールボックスが必要です。対して SMTP リレーは送信用のライセンス付きメールボックスを必要としませんが、接続条件があります。証明書を使えない場合は、他組織と共有していない固定パブリック IP アドレスが必要です。

Direct Send も別方式です。外部メールサーバーとして認証なしで直接送信しますが、Microsoft 365 を介したインターネット宛てのリレーには対応しません。外部宛ての通知がある場合は、この制約を先に確認してください。

## 自社の通知アプリや複合機の調査手順

1. **送信元を列挙します。** 通知アプリ、定期バッチ、複合機ごとに管理担当者を決めます。
2. **接続情報を記録します。** 接続先、ポート、認証方式、利用メールボックス、機器やライブラリの名称を残します。パスワードやトークンは棚卸し表に保存しません。
3. **実際の認証方式を照合します。** 機器の設定やアプリの実装を確認し、接続先やポートだけで基本認証と判定しないでください。
4. **管理者設定を確認します。** 組織とメールボックスの SMTP AUTH 設定に加え、セキュリティの既定値も確認します。
5. **移行先と検証期限を決めます。** 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 手順](https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth)では、アクセストークンの送信に SASL XOAUTH2 を使います。パスワードやポートを変えるだけの作業ではありません。

OAuth 非対応の複合機は、メーカーに対応機種や更新方法を確認します。SMTP リレーを検討する場合は、先に証明書や固定 IP アドレスの条件を満たせるかを調べてください。

アプリを改修できるなら Microsoft Graph も候補です。[Graph の sendMail 仕様](https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0)では、JSON または MIME でメッセージを送信します。職場・学校アカウントの委任アクセス許可とアプリケーションのアクセス許可には、`Mail.Send` が示されています。SMTP の接続設定だけでなく、API 呼び出しの実装が必要です。

切り替えは次の順序で進めます。

1. 自社のテスト用メールボックスと送信先を用意します。
2. 必要な権限と、管理者が許可する接続方式を確認します。
3. 自分で管理するテスト用宛先へ送信します。
4. 送信側の応答と、受信側のメッセージを照合します。
5. 失敗時の時刻、応答、対象設定を記録し、送信元ごとに段階的に切り替えます。

Graph の `202 Accepted` は要求の受付を示し、処理完了や配信完了を示しません。配信には Exchange Online の制限やスロットリングも適用されます。接続できた時点で検証を終えず、受信まで確認してください。

## Mailera の Microsoft 接続はどう関係しますか？

[Mailera の Microsoft 接続](https://mailera.app/ja/providers/microsoft)は、既存の Microsoft メールボックスに OAuth と Microsoft Graph で接続します。SMTP AUTH の基本認証を使う接続ではなく、アプリパスワードも使いません。

追加は Admin または Leader ロールで行います。

1. 「メールボックス」から「メールボックスを追加」を開きます。
2. 「Microsoftでサインイン」を選び、Microsoft 側で OAuth の同意を行います。
3. メールボックス一覧で接続状態を確認し、用途に応じた送受信テストを行います。

![Mailera のメールボックス追加画面にある「Microsoftでサインイン」タブ](https://mailera.app/media/aae6db1ea925046e/outlook-imap-smtp-add-microsoft-ja-1200.jpg)
_Microsoft メールボックスは、Microsoft 側で OAuth の同意を行って接続します。_

権限や接続準備は、[Microsoft 365 の Graph 接続チェックリスト](https://mailera.app/ja/blog/microsoft-365-graph-mail-setup)で整理できます。既存メールボックスを外部のアプリから利用する全体像は、[既存メールサービスの接続ガイド](https://mailera.app/ja/blog/connect-existing-email-to-agents)も参照してください。

Mailera は既存メールボックスを接続する製品であり、新しいメールアドレスを作成しません。既存の複合機や SMTP アプリを自動で OAuth に移行する機能でもありません。一斉配信・マーケティング送信には対応せず、受信トレイへの配信も保証しません。

導入時は [Mailera の機能範囲](https://mailera.app/ja/product)と [セキュリティ情報](https://mailera.app/ja/security)を確認してください。アプリ側の実装には [開発者向け案内](https://mailera.app/ja/developers)を使い、Microsoft 側の権限やポリシーも別途確認します。

## よくある失敗と確認点

**旧日程を社内期限として固定する。** Microsoft の該当ページで更新日と適用対象を確認し直し、社内の切り替え計画をその内容に合わせて見直します。

**SMTP AUTH を有効にすれば移行不要と考える。** 現在の許可設定と、サービス側の基本認証廃止は別です。

**接続成功だけで完了とする。** 認証、送信要求の受付、実際の受信を分けて確認します。エラーが出たら、応答を省略せずに記録し、認証方式と設定を照合してください。基本認証への切り戻しを、長期運用の前提にはしないでください。

**最初のメールボックスを2分で接続** — Outlook、Gmail、IMAPのメールボックスを追加して、アプリやAPIでメールを読めます。 [メールボックスを接続](https://mailera.app/auth?mode=signup)