Microsoft 365 のアプリとデバイスからのメール：2026年12月の変更前に確認すること

スキャナー、請求システム、レポートアプリの変更を承認する前に、Exchange Online を経由し、SMTP AUTH の基本認証を使ってメールを送信しているか確認します。Microsoft が2026年12月に変更するのは、この特定の依存関係です。組織で Microsoft 365 を使っているだけでは、各アプリの送信方法は分かりません。

実務では、影響を受ける送信元を特定し、サポートされる継続方法を確認したうえで、本番設定を変える前に代表的な業務メールを検証します。これにより、担当者や予算承認者は必要な作業を判断できます。

12月末に何が変わるのか

Microsoft のSMTP AUTH の最新スケジュールによると、2026年12月中は動作に変更はありません。12月末に、既存テナントでは SMTP AUTH の基本認証が既定で無効になります。必要な場合、管理者は引き続き有効にできます。この既定値の変更は、最終的な廃止とは別です。

2026年12月以降に作成された新しいテナントでは、既定で利用できず、OAuth がサポートされる認証方式になります。Microsoft は、最終的な廃止日を2027年下半期に発表するとしています。これは日付を発表する時期であり、廃止日そのものではありません。

このスケジュールの対象は Exchange Online SMTP AUTH の基本認証です。SMTP 自体が終了するわけでも、すべての Microsoft 365 メールボックスやデバイスが同じ方式に依存しているわけでもありません。改定された日程には準備期間がありますが、具体的な設定変更の要否は評価する必要があります。

業務メールから確認を始める

重要なメールごとに、実際の送信経路をベンダーまたは管理者に確認します。請求アプリは Exchange Online に直接送信する場合も、ローカルのリレーを使う場合も、ベンダーのサービス経由で送信する場合もあります。これらは想定例であり、それぞれ異なる確認材料が必要です。差出人欄に Microsoft 365 のアドレスがあるだけでは判断できません。

次の項目を簡潔な一覧にまとめます。

• 業務メール：何をいつ送信するのか、必要な添付ファイルや本文の内容。
• 送信元と経路：アプリまたはデバイス、実際の送信サービス、認証方式。
• 宛先：組織内、組織外、またはその両方。
• システム担当者：送信元とベンダーとの関係を管理する人。
• 継続方法の候補：サポートされる送信方法と、未解決の互換性や設定上の確認事項。
• 検証担当者：必要なメールが宛先に届いたことを確認する人。

不明点は明記し、解決する担当者を決めます。これにより、基本認証への依存が確認できた送信元と、別途調査が必要な送信元を区別できます。購入や設定変更の前に、ベンダーへ具体的な質問を提示できます。

宛先とホスティング環境に合わせて方法を選ぶ

OAuth クライアント送信は、継続方法の一つです。Microsoft のSMTP OAuth のドキュメントでは、アプリ登録やトークンを含む認証サポートについて説明しています。対象のアプリやデバイスが必要な機能を実装し、テナント設定でも利用が許可されている必要があります。製品が「SMTP に対応」とするだけでは、互換性を確認するには不十分です。該当するモデルまたはソフトウェアのバージョンについてベンダーに確認してください。

Microsoft のアプリとデバイスからの送信に関するガイダンスでは、宛先の範囲と運用要件に応じて方法を区別しています。クライアント送信と、条件を満たすコネクタリレーは組織内外の宛先に送信できます。この比較では、高容量メール（HVE）と Direct Send は組織内専用です。顧客向け請求書やリマインダーを組織外へ送る用途には使えません。

コネクタリレーには独自の利用条件があります。受信コネクタに加え、証明書または条件を満たす固定パブリック IP アドレスによる認証が必要で、ポート25が利用可能でなければなりません。Microsoft は、Azure などのサードパーティのホスティングサービスを経由したこの方式のリレーを認めていません。そのため、コネクタリレーを候補にする前に、クラウドでホストされたアプリの環境を確認する必要があります。

Direct Send を使う場合も、メールサーバーの管理責任が伴います。Microsoft が組織内外のメール向け代替手段として説明する Azure Communication Services など、別の送信サービスにも、互換性と運用面の個別評価が必要です。宛先、ホスティング環境、利用できるサポートを踏まえて、調査する選択肢を決めます。ハードウェアの交換は、サポートされる方法を確認してから判断します。

本番変更の前にメールを検証する

誰が変更を実施し、誰が業務上の結果を確認し、その後の障害に誰が対応するのかを決めます。必要な差出人情報、本文、添付ファイルを含む代表的なメールを使います。送信処理から宛先への到着までを追跡し、業務上必要であれば組織外の宛先でも確認します。

認証の成功で確認できるのは、送信過程の一部だけです。ベンダーが対応を確認し、管理者の接続テストが成功しても、業務メールが実際に届いたかを確認する必要があります。依存関係、互換性のある方法、検証の担当者が明確になってから、本番変更の日程を決めます。

アプリやデバイスからの送信に関する要件の評価をご希望の場合は、メールインフラストラクチャサービスを通じて、対象範囲をご相談いただけます。