【Microsoft 365】SMTP AUTHを無効化した後に通知メールが飛ばない時の代替案

Microsoft 365ではセキュリティ強化の一環として、従来の基本認証(SMTP AUTH)が段階的に無効化されています。その結果、これまでSMTP AUTHを利用してメールを送信していたプリンター、スキャナー、業務システムなどが通知メールを送信できなくなるトラブルが増えています。本記事では、SMTP AUTHが無効化された後に通知メールが飛ばない場合の原因切り分け方法と、実務で使える代替案を詳しく解説します。あなたの環境に合った対策を選ぶための判断材料を提供しますので、ぜひ参考にしてください。

SMTP AUTH無効化が引き起こす影響

SMTP AUTH(SMTP認証)は、メールクライアントや機器がユーザー名とパスワードを使ってメールサーバーに認証し、メールを送信するためのプロトコルです。Microsoft 365では2022年10月以降、新しいテナントではデフォルトでSMTP AUTHが無効化され、既存のテナントでも段階的に無効化が進められています。この変更により、以下のような機器やシステムからの通知メールが送信できなくなるケースが発生しています。

• 複合機やプリンターからのスキャン送信
• 監視カメラや入退室管理システムからのアラートメール
• 業務システム(ERP、CRMなど)からの自動通知メール
• スクリプトやバッチ処理からのメール送信
• オンプレミスのアプリケーションがSMTP AUTHで送信している場合

これらの機器やアプリケーションは、多くがSMTP AUTHしかサポートしておらず、 Microsoft 365が推奨するOAuth 2.0やMicrosoft Graph APIに対応していないことが多いため、代替策を講じる必要があります。

通知メールが飛ばない原因を切り分ける3ステップ

まずは、なぜメールが飛ばないのかを明確にしましょう。以下の手順で原因を特定します。

1. 送信ログを確認する: 機器やアプリケーションの送信ログ、またはExchange管理センターのメールフロー監査ログを確認します。一般的なエラーメッセージとして「550 5.7.1 Authentication unsuccessful」「535 5.7.3 Authentication unsuccessful」「503 5.5.1 Bad sequence of commands」などが表示される場合、SMTP AUTHが拒否されている可能性が高いです。
2. SMTP AUTHの有効状態を確認する: Exchange管理センター(https://admin.exchange.microsoft.com)にサインインし、「設定」→「メールフロー」→「SMTP AUTH」の順に進みます。ここで「組織全体でSMTP AUTHを有効にする」がオフになっているか、あるいは特定のユーザーの認証が無効化されていないかを確認します。また、ユーザーレベルでの設定も確認してください。「受信者」→「メールボックス」→該当ユーザー→「メールボックスの機能」→「SMTP AUTH」が無効になっていないかをチェックします。
3. 端末側の設定を確認する: 機器やアプリケーションのSMTP設定で、サーバー名が「smtp.office365.com」、ポートが587、暗号化がSTARTTLS、認証方式が「基本認証(パスワード)」になっているかを確認します。また、使用するアカウントのパスワードが正しいか、多要素認証(MFA)が有効になっていないか(MFAが有効だとSMTP AUTHは使えません)を確認します。

これらのステップで、多くの場合原因を特定できます。エラー内容や設定状況によって、後述の代替案を検討します。

代替案①: Microsoft 365のSMTPリレー(認証あり)を利用する

機器やアプリケーションがSMTP AUTHのみをサポートしている場合でも、Microsoft 365のSMTPリレー機能を使うことで、認証付きでメールを中継できます。これは最も推奨される方法で、追加のコストは原則かかりません。設定手順は以下の通りです。

1. Azure管理ポータル(https://portal.azure.com)にアクセスし、「Azure Active Directory」→「アプリの登録」→「新規登録」で、リレー用のアプリケーションを登録します(名前は任意)。
2. 登録したアプリの「証明書とシークレット」でクライアントシークレットを作成し、メモします(後で使います)。
3. 同じアプリの「APIのアクセス許可」で「Microsoft Graph」→「アプリケーションの許可」→「Mail.Send」を追加し、管理者の同意を与えます。
4. Exchange Onlineのコネクタを作成します。Exchange管理センターで「メールフロー」→「コネクタ」→「新しいコネクタ」→「組織からメールを送信する」を選択し、以下の設定を行います。条件: 「次のIPアドレスからのメッセージのみを受け入れる」に機器の送信元IPアドレスを入力(固定IPが必要)。認証: 「前述の証明書ベースの認証」を選び、先ほど作成したアプリのクライアントIDとシークレットを入力します。
5. 機器側のSMTP設定を変更します。サーバー名は「smtp.office365.com」のまま、ポート587、STARTTLS、認証方式を「基本認証」ではなく「OAuth2.0」または「XOAUTH2」に変更できる場合はその設定にします。できない場合は、SMTP AUTHを使った従来の設定のままで、ポート25(サブミッションポート)を使う方法もありますが、多くの環境ではブロックされているため推奨しません。

この方法は、アプリケーションがOAuth2.0に対応している場合に有効です。対応していない機器の場合は、次の代替案を検討します。

代替案②: SMTP AUTHを特定の条件で部分許可する

どうしても機器側がOAuth2.0に対応できず、かつSMTP AUTHを完全に無効化できない場合、限定的にSMTP AUTHを許可する方法があります。ただし、これは一時的な回避策であり、セキュリティリスクを伴うため慎重に検討する必要があります。

1. Exchange管理センターで「設定」→「メールフロー」→「SMTP AUTH」を開き、「組織全体でSMTP AUTHを有効にする」をオフのままにする(基本は無効を維持)。
2. 「受信者」→「メールボックス」→該当ユーザー(機器で使用するメールボックス)→「メールボックスの機能」で「SMTP AUTH」を有効にします。このユーザーだけSMTP AUTHが使えるようになります。
3. ただし、この方法ではMFAが無効のアカウントが必要です。そのため、専用のサービスアカウントを作成し、パスワードの複雑さを確保した上で、最小限の権限(送信のみ)を付与します。
4. また、条件付きアクセスポリシーを利用して、特定のIPアドレスからのみSMTP AUTHを許可するように制限することも可能です。Azure ADで「条件付きアクセス」→「新しいポリシー」を作成し、「クライアントアプリ」で「Exchange ActiveSync クライアント」や「その他のクライアント」を対象に、「アクセス権の付与」で「アクセスをブロック」とする代わりに、「アクセスを許可」の条件にIPアドレスを追加します。

この方法は、あくまで移行期間中の暫定策として利用し、将来的にはより安全な方法へ移行する計画を立てる必要があります。

代替案③: サードパーティのメール中継サービスを利用する

上記の方法が使えない場合、サードパーティのSMTP中継サービスを利用する手があります。代表的なものとして、SendGrid、Mailgun、Amazon SES、SparkPostなどがあります。これらのサービスを経由してMicrosoft 365にメールを配信するか、直接受信者に届けることも可能です。

• SendGrid: 無料枠(1日100通まで)があり、少量の通知メールに向いています。SMTP認証に対応しており、APIキーを使って認証します。
• Mailgun: 独自ドメインを利用でき、送信レピュテーション管理が可能です。SMTP認証のほか、API送信にも対応しています。
• Amazon SES: AWS環境と連携しやすく、大量送信にもスケーラブルです。SMTP認証とIAM認証をサポートしています。

これらのサービスを利用する場合、機器側のSMTP設定を各サービスのエンドポイントに変更するだけで済むため、機器側の変更が最小限で済みます。ただし、コストが発生する可能性があること、および外部サービスへの依存が生じることを考慮する必要があります。会社のセキュリティポリシーに抵触しないか、事前に確認してください。

代替案の比較表

代替案	メリット	デメリット	設定難易度
SMTPリレー(認証あり)	・追加コストなし ・セキュリティを維持できる	・機器がOAuth2.0対応必須 ・固定IPが必要	中〜高
SMTP AUTH部分許可	・機器設定変更不要 ・すぐに導入可能	・セキュリティリスク ・一時的な対策	低
サードパーティ中継	・機器設定変更が最小限 ・多機能・高信頼	・ランニングコスト ・外部依存・ポリシー確認	低〜中

各代替案の特性を理解し、自社の環境や要件に合ったものを選択してください。

失敗パターンと管理者に伝えるべきポイント

実際の現場でよくある失敗パターンと、管理者に伝えるべき情報をまとめます。

• 失敗パターン1: 機器側の設定ミス – サーバー名やポート番号を間違えて設定しているケース。特にポート587の代わりにポート25を使おうとしてブロックされることが多いです。設定を再確認しましょう。
• 失敗パターン2: アカウントにMFAが有効 – SMTP AUTHはMFAと併用できません。専用のサービスアカウントを作成し、MFAを無効にしてください。ただし、MFA無効アカウントはセキュリティリスクとなるため、条件付きアクセスでIP制限をかけるなど対策が必要です。
• 失敗パターン3: 組織全体のポリシーを無視 – 管理者がSMTP AUTHを完全無効化しているにもかかわらず、部分許可を試みるとセキュリティ違反になります。必ず管理者と相談し、承認を得た上で設定変更を行ってください。
• 管理者に伝えるべき情報: どの機器/アプリがSMTP AUTHに依存しているか、送信頻度、利用するメールアドレス、固定IPの有無、OAuth2.0対応の有無などをリストアップして伝えましょう。管理者はその情報をもとに、最適な代替案を判断します。

よくある質問(FAQ)

Q. SMTP AUTHを無効化した後も、一部のシステムだけメール送信できるようにするには?

A. 代替案②の「SMTP AUTH部分許可」が該当します。特定のメールボックスのSMTP AUTHを有効にし、条件付きアクセスで送信元IPを制限することで、リスクを抑えられます。ただし、長期的には推奨されません。

Q. プリンターがOAuth2.0に対応していない場合はどうすればいいですか?

A. プリンターのファームウェアアップデートで対応する場合があります。メーカーに問い合わせてください。対応しない場合は、サードパーティのメール中継サービスを利用するか、SMTP AUTH部分許可を検討します。

Q. 送信元IPが固定でないとSMTPリレーは使えませんか?

A. 原則として固定IPが必要です。動的IPの場合は、コネクタでIP範囲を広く設定する方法もありますが、セキュリティが低下します。代替案として、サードパーティサービス経由で送信するか、SMTP AUTH部分許可(IP制限なし)は避けるべきです。

Q. コストをかけずに済む方法は?

A. 代替案①のSMTPリレー(認証あり)は追加コストなしで利用可能です。ただし、機器のOAuth2.0対応が前提です。対応していない場合は、SMTP AUTH部分許可もコストゼロですが、セキュリティリスクを許容できる場合に限ります。

まとめ

SMTP AUTH無効化後の通知メール不達は、適切な代替案を選ぶことで解決できます。まずは原因を切り分け、機器の対応状況やセキュリティポリシーに合わせて、Microsoft 365のSMTPリレー、部分許可、サードパーティ中継サービスのいずれかを選択してください。特にSMTP AUTH部分許可は緊急時の暫定策として有効ですが、長期的にはより安全な方法への移行を計画しましょう。管理者と連携しながら、安定したメール送信環境を維持することをお勧めします。

👥

Teams/Outlookトラブル完全解決データベース サインイン、接続エラー、メール送受信の不具合など、特有のトラブル解決策を網羅。困った時の逆引きに活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。