2026年11月10日

[Windows Server] SMTP AUTH廃止後の自動メール通知

Windows Serverでのバックアップ結果やUPSでのイベントなどを、PowerShellでメール送信する仕組みにすることは、よくあると思います。Send-MailMessageでメールサーバを指定して送る構成です。

利用するのがExchange Online(Microsoft 365)である場合、この構成では2026年12月末以降、送信できなくなります。Exchange OnlineがSMTP AUTHの基本認証を既定で無効にするためです。Send-MailMessage自体も、Microsoftが今はもう使わないように勧めています。

置き換え先のGraph APIでは、Microsoft Entra IDに登録したアプリがメールを送ります。作り直しで留意すべき点は、そのアプリにどこまでの送信を許すかと、認証情報をどう管理するかを決めるところです。

本記事は、このExchange Online経由の構成を前提としています。Google Workspaceや他のメールサーバから送っている場合、Exchange OnlineのSMTP AUTH廃止の影響は受けませんが、権限の絞り方や認証情報の管理等は、参考になる場合があります。

2026年12月末、基本認証は既定で無効になる

Exchange OnlineのSMTP AUTH基本認証は、当初2025年9月に廃止される予定でした。その後、2026年3月開始・4月末完了に延期され、さらに、2026年1月に現在の予定が公表されています¹。

2026年12月まで:動作は変わらない
2026年12月末:既存テナントの既定値が無効に変わる。管理者が有効にすれば引き続き使える
2026年12月より後に作成する新規テナント:既定で利用できない。OAuthが標準になる
2027年後半:最終的な廃止日が発表される

12月末以降も、管理者が有効に戻せば当面はこれまでどおり送れます。ただし、有効に戻せるのは最終的な廃止日までで、その日付は2027年後半に発表される予定です。戻して使い続けると、いつ止まるか分からないというリスクを抱えることになります。

自分のテナントで基本認証を使って送信している機器やスクリプトがあるかは、Exchange管理センターの「レポート」＞「メールフロー」＞「SMTP AUTH クライアントのレポート」で確認できます²。

Send-MailMessage自体も非推奨

PowerShellのSend-MailMessageコマンドレットは、Microsoftのリファレンスで廃止扱いになっています³。PowerShell 7以降では、実行すると次の警告が出ます。

警告: コマンド 'Send-MailMessage' は廃止されています。 This cmdlet does not guarantee secure connections to SMTP servers...

Windows Server標準のPowerShell 5.1では警告は出ないため、5.1でスクリプトを動かしていると廃止扱いであることに気づけない可能性があります。

このコマンドレットはOAuth 2.0に対応しておらず、Exchange Onlineの基本認証が無効になれば、Exchange Online経由の送信には使えなくなります。認証不要の社内SMTPリレー宛てなら動きますが、リファレンスはその場合も使わないよう勧めています³。

Exchange Online経由で送り続ける場合の置き換え先は、Microsoft Graph APIです。PowerShellからは、Microsoft Graph PowerShell SDKに含まれるSend-MgUserMailコマンドレットを使います。

Graph APIへの置き換え

従来のSMTP AUTHでは、メールアドレスとパスワードを直接渡していました。Graph APIでは、Microsoft Entra IDにアプリを登録し、そのアプリにメールを送る権限を与え、アプリの認証情報(クライアントシークレットまたは証明書)で認証します。

認証部分のコードは下記のようなものです。

# クライアントシークレット認証(Microsoft Graph PowerShell SDK)
$secureSecret = ConvertTo-SecureString -String $clientSecret -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($clientId, $secureSecret)
Connect-MgGraph -TenantId $tenantId -ClientSecretCredential $credential -NoWelcome

Send-MgUserMail -UserId $from -BodyParameter $params

Mail.Send権限の既定の影響範囲は、テナント全体

Graph APIでメールを送るアプリには、「Mail.Send」というアプリケーション権限を与えます。この権限で許されるのは、任意のユーザーとしてのメール送信です⁴。

通知用メールアドレスから送るつもりで作ったアプリでも、既定のままではテナントの全てのアドレスを差出人にできるため、クライアントシークレットが漏れた場合、攻撃者はその会社の任意のアドレスを名乗ることができてしまいます。

このリスクを避けるため、送信できるメールボックスを絞る仕組みとして、Exchange Onlineには「RBAC for Applications」があります⁵。Exchange Online側でアプリに送信の役割を割り当て、その範囲を特定のメールボックスに限定する機能です。以前から使われてきた「Application Access Policy」は、RBAC for Applicationsに置き換えられる位置づけになっています⁵。

これを使う場合、Entra ID側の同意は外しましょう。Entra IDで与えた権限と、RBAC for Applicationsで与えた権限は別に働き、どちらかで許されていれば送信できます。Entra IDで全体のMail.Sendを与えたままにすると、Exchange Online側で範囲を絞っても、すべてのメールボックスから送れてしまいます⁵。

クライアントシークレットの有効期限

アプリの認証情報として最も手軽なのが、クライアントシークレットです。文字列で発行され、コードの中で使います。有効期限は最長24か月で、それより長くは設定できません⁶。

Microsoftが勧める有効期限は12か月未満です⁶。24か月は設定できる上限で、短いほどセキュリティを高められますが、更新の手間が大きくなります。

有効期限が切れるとメール送信が止まるため、下記のような対処をしておきましょう。

作成日と有効期限を、スクリプト内のコメントや、管理表などに記録する
有効期限前に更新を済ませられるよう、リマインドを設定しておく
更新の手順を文書にし、複数人が作業できるようにする

証明書認証

クライアントシークレットのほかに、証明書でも認証できます。Microsoftは、アプリを運用環境に移す前に、シークレットから証明書へ切り替えることを勧めています⁷。

シークレットは文字列を知っていれば認証、証明書は秘密鍵を持っていなければ認証できません。秘密鍵は、エクスポートできない設定で証明書ストアに置けます。文字列はコピーすれば持ち出せますが、エクスポートできない秘密鍵は同じようには持ち出せません。

整理すると下記のとおりです。

	クライアントシークレット	証明書
認証に使うもの	文字列(パスワードに相当)	証明書と、対になる秘密鍵
有効期限	最長24か月。Microsoftの推奨は12か月未満	証明書の発行時に決まる。自己署名なら作成時に指定できる
持ち出しやすさ	文字列をコピーすれば持ち出せる	秘密鍵をエクスポート不可にすれば、持ち出しにくい
導入の手間	管理画面から数クリックで作成できる	証明書の作成、Entra IDへの登録、サーバーへの配置が必要
向いている用途	テスト・初期構築	本番運用

証明書は無償でも用意できます。Windowsに標準で入っているNew-SelfSignedCertificateコマンドレットで自己署名証明書を作り、公開鍵をEntra IDに登録します⁸。ただし、Microsoftは自己署名証明書をテスト用として案内しています。社内に証明機関があり、証明書の発行や失効をまとめて管理している場合は、そちらで発行すると管理を揃えられます。

最初はクライアントシークレットで動かし、あとで証明書に移す進め方も現実的だと思います。長く使うシステムや、認証情報が漏れると業務に響くシステムでは、構築の段階で証明書へ移す時期を決めておきます。

3つの組み合わせ

権限の絞り方、シークレットの期限管理、証明書への移行の3つは互いに関係していて、どれも安全側に寄せるほど構築と運用の手間が増えます。

たとえば、証明書認証を選び、RBAC for Applicationsで送信元を通知用のメールボックスに絞る組み合わせは、漏れたときの被害を最も小さくできますが、初期構築の手間は最も大きくなります。反対に、24か月のシークレットを発行して権限も絞らない組み合わせは、すぐに動かせる代わりに、漏れたときの被害が大きくなります。

どこまで寄せるかは、システムの重要度と運用体制で決めます。実務上は、権限の絞り込みを最初に済ませておくのがよいのではないでしょうか。Exchange Online側の作業で完結し、一度設定すれば以降の手間はほとんどないためです。

メールが来ない場合に調査を始める運用

Windows Serverバックアップは、成功時にイベントID 4、失敗時にイベントID 5を、Microsoft-Windows-Backup/Operationalログに記録します。この2つのイベントを契機にメールを送る構成はよく見られます。

ただし、サーバーが止まっていた、スケジュールの設定が消えていた、といった理由でバックアップ自体が動かなかった日は、どちらのイベントも記録されず、メールも送られません。失敗時だけ通知する構成では、この日は成功した日と見分けがつきません。

成功時にも通知を送り、毎日決まった時刻までにメールが届かなければ異常とみなす運用にしておけば、原因が何であっても、届かない時点で調べ始められます。バックアップが動かなかった場合も、シークレットの期限切れで送信が止まった場合も、同じ仕組みで気づけます。

まとめ

SMTP AUTH廃止に伴うメール通知の作り直しでは、次の点を意識しておきましょう。

2026年12月末に基本認証は既定で無効になる。有効に戻すことはできるが、最終的な廃止日は2027年後半に発表される予定で、まだ決まっていない
Send-MgUserMailへの置き換えでは、Entra IDにアプリを登録し、権限と認証情報を設計する
Mail.Sendは既定でテナント内のすべてのメールボックスから送信できる。RBAC for Applicationsで絞るときは、Entra ID側のMail.Sendの同意を外す
クライアントシークレットの有効期限は最長24か月、Microsoftの推奨は12か月未満。期限の記録と更新の手順を用意する
バックアップの通知は成功時にも送り、届かない日を異常とみなす。原因を問わず、届かない時点で調べ始められる

メール通知のような「動いて当たり前」の仕組みは、普段はあまり意識されず動いています。Graph APIへの移行では、送信の権限やシークレットの期限といった、これまでなかった管理項目が加わります。移行作業だけでなく、作ったあとに誰が何を管理するかまで決めておくと、次に止まる原因を減らせます。

本記事の内容は可能な限り確認しておりますが、環境やバージョン、Microsoftの仕様変更などによって結果が異なる可能性があります。重要な本番環境で実施される際は、事前のテスト環境での検証と、認証情報の安全な管理をお勧めします。判断に迷われる場合は、専門家にご相談ください。

まるっと (IT総合支援サービス)

「止めない」「守る」「活かす」の3つの柱で、お客さまのIT基盤をトータルに支えます。専任の情報システム担当がいらっしゃらない企業さまも、お気軽にご相談ください。
▸ サービス詳細: https://www.distant-view.co.jp/service/marutto.html
▸ お問い合わせ: https://www.distant-view.co.jp/contact/

出典・参考リンク

出典・参考リンクは2026年11月時点で内容を確認しています。リンク先は予告なく変更・削除される場合がありますので、最新の公式情報をあわせてご確認ください。

SMTP AUTH基本認証の廃止スケジュールについて。Japan Exchange & Outlook Support Blog「Exchange Online における SMTP AUTH 基本認証廃止スケジュールの更新のご案内」: https://jpmessaging.github.io/blog/Updated-Exchange-Online-SMTP-AUTH-Basic-Authentication-Deprecation-Timeline/ ↩︎
基本認証で送信している機器の確認方法について。Microsoft Learn「Exchange Online の新しい Exchange 管理センターでの SMTP AUTH クライアントレポート」:
https://learn.microsoft.com/ja-jp/exchange/monitoring/mail-flow-reports/mfr-smtp-auth-clients-report ↩︎
Send-MailMessageが廃止扱いであることについて。Microsoft Learn「Send-MailMessage」:
https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.utility/send-mailmessage ↩︎
Mail.Send権限の内容について。Microsoft Learn「Microsoft Graph のアクセス許可のリファレンス」:
https://learn.microsoft.com/ja-jp/graph/permissions-reference ↩︎
RBAC for Applications、Application Access Policyとの関係、Entra IDの権限との関係について。Microsoft Learn「Role Based Access Control for Applications in Exchange Online」: (英文)
https://learn.microsoft.com/ja-jp/exchange/permissions-exo/application-rbac ↩︎
クライアントシークレットの有効期限について。Microsoft Learn「Microsoft Entra ID でアプリの資格情報を追加および管理する」(「クライアントシークレットの追加」タブ):
https://learn.microsoft.com/ja-jp/entra/identity-platform/how-to-add-credentials ↩︎
運用環境では証明書を使うことの推奨について。Microsoft Learn「Microsoft Entra ID でアプリの資格情報を追加および管理する」:
https://learn.microsoft.com/ja-jp/entra/identity-platform/how-to-add-credentials ↩︎
自己署名証明書の作成と、テスト用とされていることについて。Microsoft Learn「自己署名公開証明書を作成してアプリケーションを認証する」:
https://learn.microsoft.com/ja-jp/entra/identity-platform/howto-create-self-signed-certificate ↩︎