Azure VM上のExchangeから「受信はできるのに送信だけ失敗する」場合、原因はNSGやWindows Firewallではなく、Azure側がSMTP(TCP 25)をサブスクリプション単位で強制ブロックしているケースが少なくありません。本記事では、移行直後に起きる理由、解除可否の判断、Exchangeハイブリッドでの注意点と代替策を整理します。
起きている現象を整理する
まず、今回のようなトラブルは「Exchangeが壊れた」というより、ネットワーク上でSMTPの出口だけが塞がれている状態で説明できることが多いです。
- インターネット宛てのメール送信だけが失敗する（SMTP / TCP 25）
- 外部からの受信はできている（MXや受信コネクタ側は生きている）
- VMを別サブスクリプションへ移動した直後から発生
- 旧サブスクリプションでは例外申請が通っていた
この条件が揃うときは、サブスクリプション種別が変わったことで、Azureプラットフォーム側の「アウトバウンドTCP 25制限」が有効化された可能性が最優先の疑いポイントです。
Azureで「ポート25が開かない」最大の理由はサブスクリプション制限
Azureではスパム送信やIPレピュテーション悪化の防止を目的に、VMからのアウトバウンドSMTP（TCP 25）をプラットフォーム側でブロックする仕組みがあります。重要なのは、これはNSGやOSのファイアウォールとは別レイヤーで行われるため、VM側でいくら許可ルールを作っても解決しないケースがあることです。
さらに厄介なのが「以前は送れていたのに、ある日突然送れなくなった」パターンです。Azure公式のトラブルシューティングでも、サブスクリプション種別を変更すると、配置の変更を契機にアウトバウンドSMTPがブロックされ得ることが明記されています。
サブスクリプション種別ごとのポート25扱い（早見表）
「解除できるかどうか」は、技術的というより契約・サブスクリプションの種類でほぼ決まります。
| サブスクリプションの系統 | VMのアウトバウンドTCP 25 | 現実的な対応 | 補足 |
|---|---|---|---|
| Enterprise Agreement（EA）/ MCA-E（企業向け契約） | 原則ブロックされない | それでも送れない場合はネットワーク/送信先側の制限を疑う | 外部ドメイン側が受け入れない可能性は別途あり。 |
| Enterprise Dev/Test | 既定でブロック | Azureポータルの診断から解除（例外）を申請 | 解除後はVMの停止・割り当て解除→起動が必要。 |
| 上記以外（クレジット系、試用、一般的な従量課金など） | プラットフォーム側でブロック（原則解除不可） | 25番直送は諦め、認証付きSMTPリレー（587）等へ設計変更 | VMからのTCP 25直送は推奨されず、代替手段が案内される。 |
質問の「MVP特典クレジット」のようなクレジット系サブスクリプションは、一般にこの「上記以外」に該当しやすく、VMからインターネットへTCP 25を開ける前提の運用は継続できないと考えた方が安全です。
PaaS（App Service / Functions）ならポート25が使えることがある
同じAzureでも、App Service や Azure Functions は、仮想ネットワーク統合や App Service Environment v3 を利用することで、アウトバウンドTCP 25で送信できる構成があります。一方で、ポート25の扱いはあくまでサブスクリプション種別の制限に左右されるため、「PaaSにすれば必ず解決」という話ではありません。
また、Azure Firewall 経由でポート25送信を行う構成も可能ですが、やはりサブスクリプション側の制限は適用されます（Firewallを挟んでも“解除不可”が“解除可”になるわけではありません）。
切り分けは必要だが、最短で結論に到達するコツ
「本当にサブスクリプション制限なのか」を確認するには、闇雲に設定を触るより、到達性テスト → どのレイヤーで止まっているかを短時間で見極めるのが重要です。
到達性テスト（送信先を固定して確認）
Exchange Onlineや一般的な外部SMTPサーバーに対して疎通を試すと、問題が再現しやすくなります。
Test-NetConnection -ComputerName smtp.office365.com -Port 25
Test-NetConnection -ComputerName smtp.office365.com -Port 587結果の読み方の目安は次の通りです。
| 状況 | Test-NetConnectionの傾向 | 疑うべき原因 |
|---|---|---|
| 25だけ失敗、587は成功 | 25: TcpTestSucceeded=False / 587: True | サブスクリプション制限（Azureプラットフォームブロック）やISP側25ブロック |
| 25も587も失敗 | 両方False | NSG/UDR/Firewall/プロキシ/経路（NAT）などネットワーク全体の問題 |
| 25は成功だがメールが届かない | TcpTestSucceeded=True | DNS/証明書/TLS/送信先側の拒否（IPレピュテーション等） |
なお、OSのWindows Defender ファイアウォールやNSGで「許可しているのに送れない」場合でも、Azureプラットフォーム側のブロックであれば診断上は「VMの外」に原因があるため、設定変更で改善しません。
Azureの診断機能を使う
Enterprise Dev/Testなど、解除申請の導線が用意されている場合は、AzureポータルのDiagnose and Solve Problemsから「Cannot send email (SMTP – Port 25)」診断を実行し、手順に沿って例外申請を行います。
Enterprise Dev/Testでの解除申請（できること・できないこと）
Enterprise Dev/Testでは、既定で25番がブロックされていますが、条件を満たす場合はブロック解除が可能です。重要ポイントは次の通りです。
- 解除は「VM単体」ではなく、サブスクリプション単位で例外扱いになる。
- 解除後はVMを停止（割り当て解除）して再起動しないと新しいネットワークポリシーが適用されない。
- 例外が適用されるのは、インターネットへ直接ルーティングされるVMトラフィックに限られる。
実運用では、解除後に「再起動したのに変わらない」という声が出やすいので、停止（割り当て解除）→起動まで確実に実施してください。
解除できない場合の代替案：設計を「25直送」から切り替える
ポート25を開けられないサブスクリプションでは、最終的に「インターネット宛てメール送信の方式そのもの」を変える必要があります。Azure公式の推奨は、認証付きSMTPリレー（多くはTCP 587）の利用です。
代表的な選択肢（アプリ/デバイス向け）
| 方式 | 主なポート | 用途の相性 | 注意点 |
|---|---|---|---|
| Exchange OnlineのSMTP AUTH（クライアント送信） | 587（推奨） | アプリ通知、レポート送信、スキャンToメール | SMTP AUTHは管理側で無効化されている場合がある／OAuth対応が重要。 |
| Azure Communication Services Email（SMTP認証） | 587（推奨） | クラウドネイティブな通知メール、システムメール | 送信上限（レート制限）や要件確認が必要。 |
| SendGridなどのサードパーティSMTPリレー | 587/465（サービス依存） | 大量配信、トランザクションメール | 契約・料金・到達率（ドメイン認証）を含めて設計が必要。 |
ここで重要な落とし穴として、Microsoft 365の「SMTPリレー（コネクタ方式）」はTCP 25が必須であり、さらにMicrosoft Azureのようなホスティング環境からは利用できないと明記されています。Azure上からの送信で困っている場合は、同じMicrosoft 365でも「SMTP AUTH（587）」側を検討するのが基本線です。
Exchangeサーバーからの送信だけを回避する（スマートホスト + 587）
「アプリではなく、Exchangeそのものが外部宛てに送れない」ケースでも、ハイブリッド要件を満たす必要がない範囲（例：インターネット向けの通常送信だけ）であれば、スマートホスト経由に切り替えることで回避できることがあります。
Exchangeの送信コネクタはDNSで外部へ直接配送するときは基本的にTCP 25を使いますが、スマートホスト転送を使う場合は、スマートホスト側のポート番号（既定25）を変更できることが公式ドキュメントに示されています。
考え方はシンプルで、次のように「Azureではブロックされにくい587で受けてくれる中継サービス（SMTPリレー）へ投げる」形です。
- Exchange →（587）→ 外部SMTPリレー（認証あり）→ インターネット
設定例（概念）としては、送信コネクタをスマートホストに向け、必要に応じてポートを587へ変更します。
# 既存の送信コネクタを確認
Get-SendConnector
# 送信コネクタをスマートホスト転送にし、ポートを587へ（スマートホストが587を受ける前提）
Set-SendConnector -Identity "To-SMTP-Relay" -SmartHosts smtp.example.net -Port 587ただし、この方法はExchangeハイブリッドのサーバー間メールフロー（Exchange Online ⇔ Exchange）を587に置き換える話ではありません。ハイブリッドのセキュアメールトランスポートはTCP 25前提なので、「ハイブリッドを維持したい」要件がある場合は、この回避策だけでは根本解決にならない点に注意してください。
ポート465を避けたい理由（特にMicrosoft 365連携）
ポート465（SMTPS）は機器やサービスによっては提示されますが、Microsoft 365のガイドでは465を推奨せず、デバイス側が465を前提にしている場合「必要なTLSバージョンに対応していない可能性」を指摘しています。メール送信の近代化（TLS 1.2/1.3、OAuthなど）を考えると、587 + STARTTLSに寄せる方が長期運用では安全です。
Exchangeハイブリッド構成での結論：25以外に置き換えできない
質問の核心である「Exchangeハイブリッドを587/465で維持できるか」については、結論から言うとできません。
Microsoft Learnのハイブリッド前提条件では、オンプレミス側（今回ならAzure VM上のExchangeを“オンプレ相当”として使う場合）とExchange Onlineの間で、TCP 25（SMTP/TLS）を使ったセキュアメールトランスポートが必要であることが、プロトコル・ポート表として明示されています。
| 通信の目的 | 使うポート | 誰と誰の通信か | ポイント |
|---|---|---|---|
| ハイブリッドのメールフロー（サーバー間SMTP） | 25（SMTP/TLS） | Exchange Online ↔ ハイブリッド対象のExchange（Mailbox/Edge等） | コネクタは25前提。587/465に変更する設定は用意されない。 |
| ハイブリッドの各種サービス（Autodiscover/EWSなど） | 443（HTTPS） | Exchange Online ↔ 公開されたExchangeエンドポイント | メールフローとは別系統。443だけ開いてもメールフローは成立しない。 |
| クライアント送信（SMTP SUBMISSION） | 587 | メールクライアント/アプリ ↔ サーバー | Exchange Serverの認証付き送信は587が標準。 |
つまり、Azure側の制約で25番がどうしても出られない環境にExchangeハイブリッドの送信口（ハイブリッドエンドポイント）を置くと、ハイブリッドのサーバー間メールフローが成立しない、という設計上の問題になります。
今回のケースで取りうる現実的な対応パターン
「何を守りたいか（ハイブリッドの要件か、単なる通知メールか）」で最適解は変わります。ここでは現場で採用されやすいパターンを整理します。
ハイブリッドのメールフローを維持したい（最優先）
- ポート25がブロックされないサブスクリプション（EA/MCA-E）へ戻す、またはEnterprise Dev/Testなら解除申請を行う。
- 難しければ、ハイブリッド用のExchange（またはEdge）だけはオンプレ/別環境に置く（25が双方向に通る場所）。
- 「VMはそのまま、587へ切り替え」はできないため、インフラ側の置き場所を変えるのが基本。
ハイブリッドは維持するが、アプリ通知メールだけは別経路に逃がしたい
- Exchangeを経由させず、アプリから直接SMTP AUTH（587）やACS Emailへ送信する（用途を分離）。
- 運用面では、差出人ドメインのSPF/DKIM/DMARCや送信制限の設計を先に固めると事故が減る。
そもそもインターネット宛てメール送信をExchangeに背負わせない
Exchangeは本来「組織メール」を扱う基盤で、通知メール（大量/定型）とは性格が違います。Azureで25番制約に当たったことを機に、通知は専用サービスへ寄せ、Exchangeは組織メールとハイブリッド要件に集中させる構成にすると、障害点も減らせます。
運用でハマりやすい注意点
「送れた＝届く」ではない
EA/MCA-Eなどで25番が通ったとしても、外部プロバイダー側がAzureの送信IPを迷惑メール扱いにするなど、受け入れ拒否が起きることがあります。Azure公式も「外部ドメインが受け入れる保証はない」旨を明記しており、到達性やレピュテーションは送信先側のポリシー影響を受けます。
ハイブリッドのSMTPは「途中で加工しない」構成が前提
Exchangeハイブリッドでは、オンプレとクラウド間のセキュアメールフローがメッセージ内情報に依存するため、SMTPを加工・改変する中継装置を挟む構成は推奨されません。ファイアウォールは「TCP 25をそのまま通す」形がサポートされます。
SMTP AUTH（587）を使うなら「認証方式の将来」も考える
Microsoft 365のSMTP AUTHは587で利用できますが、近年はセキュリティ強化の流れが速く、運用方針の見直しが必要になることがあります。たとえば、Exchange OnlineのSMTP AUTH（Client Submission）については、Basic認証が2026年3月1日から段階的に拒否され、2026年4月30日に100%拒否へ到達するスケジュールが告知されています。これから設計変更をするなら、OAuth対応や、Azure Communication Services Email / High Volume Emailなどの代替手段も含めて検討しておくと手戻りが減ります。
まとめ
Azure VMを別サブスクリプションへ移動した直後にSMTP 25の送信だけが失敗する場合、原因はExchangeの設定よりもサブスクリプション種別に紐づくAzure側のアウトバウンドTCP 25制限であることが多いです。
- EA/MCA-Eでは25番がブロックされないのが基本だが、外部側の受け入れ問題は別途あり。
- Enterprise Dev/Testは診断から解除申請でき、解除後は割り当て解除→起動が必要。
- それ以外の多くのサブスクリプションでは25番直送は解除できないため、認証付きSMTPリレー（587）へ設計変更が現実的。
- Exchangeハイブリッドのサーバー間メールフローは25番前提で、587/465への置き換えはできない。
結局のところ、ハイブリッド要件（25必須）を守るなら置き場所を変える、通知メールが目的なら送信サービスを分離する、この2軸で設計を組み直すのが、再発防止も含めた最短ルートです。
コメント