kintoneのメール送信と基本認証の終了
kintone環境のどこかで、ユーザー名とパスワードを保存してメールを送っている場合 — JavaScriptカスタマイズ、バッチ処理、テナント経由で送信している複合機 — 期限が迫っています。Gmailはすでに終了済み。Microsoftは2026年12月末に、既存のExchange Onlineテナントで既定を無効化します。
何が止まるのか
基本認証とは、ユーザー名とパスワードをメールサーバーに送る方式です。Microsoftは2019年からExchange Onlineでの撤廃を進め、EAS・POP・IMAP・EWS・PowerShellについては2022年末に完了しました。SMTP AUTH のクライアント送信だけが例外として残っており、それが今まさに閉じられようとしています。
拒否されたクライアントには 550 5.7.30 Basic authentication is not supported for Client Submission が返ります。5xx の恒久エラーであるため、送信側はリトライしません。キューに溜まって後で届くのではなく、そのまま消えます。監視していなければ誰も気づきません。
スケジュール
| 時期 | 内容 |
|---|---|
| 2022年に完了 | Exchange Online の EAS・POP・IMAP・EWS・PowerShell では基本認証を撤廃済み。SMTP AUTH のみが例外として残っていました。 |
| 現在 〜 2026年12月 | SMTP AUTH の基本認証は従来どおり動作します。 |
| 2026年12月末 | 既存テナントで既定が無効に。管理者による一時的な再有効化は可能です。 |
| 2027年1月以降 | 新規テナントでは利用不可。OAuth が正式な認証方式になります。 |
| 2027年下半期 | 完全撤廃の最終日が告知される予定です。 |
上記はMicrosoftが公開しているスケジュール（2026年1月27日更新）に基づきます。過去に複数回の延期があるため、計画時はMicrosoft 365 メッセージセンターで最新情報をご確認ください。
なぜkintone環境で影響が大きいのか
kintoneには、レコードから任意の業務メールを送る標準機能がありません。そのため必要な組織はたいてい、SMTP認証情報を埋め込んだJavaScriptカスタマイズ、第三者の配信サービスを経由するプラグイン、kintone外のバッチ処理 — このいずれかを持っています。
1つ目は完全に停止します。2つ目は動き続けますが、送信元が自社のメールボックスではなくベンダー側の基盤になります。返信が現場の見ているメールボックスに届かず、送信済みトレイにも残らないという、別の問題が残ります。
移行先の選択肢
Microsoftが案内している方式は、OAuth 2.0 + SMTP AUTH、Microsoft Graph API、大量送信向けの High Volume Email、Azure Communication Services、ハイブリッド構成のオンプレミスSMTPリレーです。kintoneのレコードから業務メールを送る用途では、OAuth 2.0 か Graph が現実的な選択になります。
難所はトークン取得そのものではありません。リフレッシュトークンの保管とローテーション、そして 共有メールボックスからの送信（Send As） です。後者は「返信が個人宛ではなく sales@ に届く」ために必須で、内製で作ると終盤に気づきがちな要件です。
今月やるべきこと
1. 棚卸し。 Exchange 管理センターの「SMTP AUTH クライアント送信レポート」に認証プロトコル列があり、基本認証かOAuthかを確認できます。まずここから。多くの組織で、忘れていた送信元（複合機やアラート通知）が見つかります。
2. 送信元ごとに判断。 OAuth非対応の機器はリレー構成へ。アプリケーションからの送信はOAuthまたはGraphへ。
3. kintone由来のものは丁寧に。 届かなかった見積書、誰にも通知されなかった承認依頼 — 失敗の先に必ず人がいるのがこの分類です。
よくある質問
Microsoftはいつ基本認証を止めるのですか？
2026年1月27日に公開されたスケジュールでは、2026年12月末に既存のExchange Onlineテナントで SMTP AUTH の基本認証が既定で無効化されます（管理者による一時的な再有効化は可能）。2027年1月以降に作成されたテナントでは利用できません。完全撤廃の最終日は2027年下半期に告知される予定です。
停止するとどのようなエラーになりますか？
550 5.7.30 Basic authentication is not supported for Client Submission が返ります。5xx の恒久エラーのため送信側はリトライせず、メールは遅延ではなく消失します。
Gmailも同じですか？
Googleはすでに同等の対応を完了しており、基本認証は利用できません。現在Gmailのパスワードでkintoneからメール送信できている場合、多くはアプリパスワードを使用しており、これは別の仕組みで別のリスクがあります。
再有効化し続けることはできますか？
最終撤廃日までの暫定措置としては可能です。ただしその最終日は2027年下半期に告知される予定で、移行までの時間を稼ぐ手段であって恒久的な解決策ではありません。
Kinplug Mail はどう対応していますか？
OAuth 2.0 で認証し、自社の Gmail / Microsoft 365 メールボックスから送信します。Send As・共有メールボックスに対応しているため、返信は実際のメールボックスに届き、送信済みトレイにも残ります。
OAuth 2.0 でkintoneからメールを送る
Kinplug Mail は OAuth 2.0 で自社の Gmail / Microsoft 365 メールボックスから送信します。Send As・共有メールボックス対応なので、返信は現場が見ているメールボックスに届きます。月額 ¥9,800（$69）の単一プランに全プラグイン込み、30日間の無料トライアルがあります。