1. はじめに

メールの設定画面で、587 と 465 のどちらを選べばいいのか迷ったことはないだろうか。
そもそも 25 は何に使うポートなのか。

結論を先に書く。

ポート番号は「どの区間か」と「どの暗号化方式か」で決まる。クライアントが送るのは 587 / 465、サーバー同士の転送は 25、受け取るのは IMAP（143 / 993）か POP3（110 / 995）。

この記事で分かること：

メールが届くまでの区間と、区間ごとに使うポート
25 / 587 / 465 の使い分けと、465 の経緯
受信（POP3 / IMAP）のポートと、平文・STARTTLS・暗黙 TLS の違い

前提

本文のドメインは例である。example.com と example.net は例示用に予約されたドメイン（RFC 2606）で、実在の環境ではない
事実は主に RFC と IANA のポート登録に依拠する。リンクは本文に載せる。動作検証はしていない整理記事である

2. 全体図

メールは 1 本の線で届くのではなく、役割の違う区間をつないで届く。
ここでは user@example.com から user@example.net へ送る例で見る。

図 1：メールの流れと区間ごとのポート

送信者の MUA から送信側のサーバーへは、587 または 465
サーバー同士の転送は 25
受信者の MUA がメールボックスから受け取るのは、IMAP か POP3

登場人物

MUA：利用者側のメールソフト。メールを作って、MSA 経由で最初の投稿を行う
MSA：MUA から投稿されたメールを受け付ける。サイトのポリシーと標準の要件を適用する
MTA：メールを 1 ホップずつ中継する。宛先の MDA に着くまで MTA が連なる
MDA：受信者の環境（メールボックス）への配送を担う

👉 受信者側の MUA は、メールボックス（メッセージストア）に POP / IMAP でアクセスする。図の矢印はメールの流れだが、IMAP / POP3 は MUA がメールを取りに行く側である。

👉 転送は 25 番のまま、という整理は RFC 6409 に書かれている。投稿（MUA → MSA）は別の区間として分けて扱う。

👉 区間ごとにポートが違う。

出典：

RFC 5598 Internet Mail Architecture：https://www.rfc-editor.org/rfc/rfc5598
RFC 6409 Message Submission for Mail（Abstract）：https://www.rfc-editor.org/rfc/rfc6409

3. 投稿（Submission）：587 と 465

MUA から MSA へメールを渡す区間。ここがメールクライアントやアプリの SMTP 設定で選ぶポートにあたる。

ポートは 587 と 465
MSA は既定で SMTP AUTH による認証を要求する（下の「認証」を参照）
暗号化の方式がポートで違う

ポート	IANA のサービス名	暗号化の方式
587	submission	平文で接続し、STARTTLS で TLS に切り替える
465	submissions	接続した直後から TLS（暗黙 TLS）

認証

RFC 6409 は、MSA は既定では SMTP AUTH で認証されていないセッションの MAIL コマンドにエラーを返さなければならない（MUST）、と定めている
すでに別の方法で認証・認可が確立している場合（保護されたサブネット内など）は例外
465 も 587 と同じく MSA に繋がるポートで、投稿（RFC 6409）が交わされる。そのため MSA への要件（RFC 6409 Section 4.3 の認証の要件など）がそのまま当てはまる（RFC 8314 Section 3.3）

👉 「必ず認証が要る」ではなく、「既定で認証を要求する」と読む。

587：STARTTLS

587 は投稿用に予約されたポート（RFC 6409 Section 3.1）
平文で接続したあと STARTTLS コマンドで TLS に上げる
RFC 6409 自体は 587 の暗号化方式を決める文書ではない。「587 は STARTTLS」という整理は RFC 8314 Section 3.3 の記述による

465：暗黙 TLS と、その経緯

暗黙 TLS では、TCP 接続が確立した直後に TLS ハンドシェイクが始まる（RFC 8314 Section 3.3）
465 の経緯は少し込み入っている（RFC 8314 Section 7.3）

465 は過去に短期間 smtps として登録された
転送ではポートを指定する手段が無く 25 が常に使われるため、この登録は取り消された
その後、465 は別のサービスに再割り当てされた
一方で、広く使われているメールソフトが smtps を「投稿」と解釈し、暗号化を選んだときの既定として 465 を使い続けた
そこで RFC 8314 が、465/TCP に submissions（Message Submission over TLS protocol）を追加の用途として登録した。RFC 8314 はこれを「一度きりの手続き上の例外」としている

👉 IANA の登録簿（2026 年 10 月時点）でも、465/TCP には submissions と urd の 2 件が並んでいる。

❌「465 は非推奨で古い」

465 は廃止・非推奨のポートではない。RFC 8314 は、投稿では平文ポートに繋いで STARTTLS で上げるより、暗黙 TLS を使うことを推奨している
推奨の対象は MUA と MSP の間のプロトコル（POP / IMAP / SMTP Submission）。サーバー同士の転送には触れていない

❌「587 は使ってはいけない」

これも言い過ぎ。RFC 8314 Section 3.3 は、465 の経緯もあって 587 の STARTTLS は比較的広く展開されているとしている
移行期間のあいだ、クライアントとサーバーは 587 の STARTTLS と 465 の暗黙 TLS の両方を実装すべき（SHOULD）とされている
実装が正しく、TLS の確立を必須にしていれば、両者のセキュリティ上の差は大きくないとも書かれている

👉 どちらを使うかは、接続先が対応しているほうを使えばよい。両方使えるなら、RFC 8314 が推奨するのは 465（暗黙 TLS）。

2525 について

2525 という番号を目にすることがあるが、

2525 は SMTP の標準ポートではない
IANA の登録簿（2026 年 10 月時点）では、2525 は SMTP 用ではなく ms-v-worlds（MS V-Worlds）に割り当てられている

出典：

RFC 6409 Message Submission for Mail（Section 3.1 / 4.3）：https://www.rfc-editor.org/rfc/rfc6409
RFC 8314 Cleartext Considered Obsolete（Section 3 / 3.3 / 7.3）：https://www.rfc-editor.org/rfc/rfc8314
IANA Service Name and Transport Protocol Port Number Registry：https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

4. 転送（Relay）：25

MTA から宛先の MTA へメールを渡す区間。ポートは 25。

SMTP サーバーは、IANA が SMTP 用に指定したポート 25 で常に待ち受けるべき（SHOULD）とされている（RFC 5321 の Receiving Strategy 節）
RFC 6409 の Abstract は、投稿と転送を分け、転送は影響を受けず 25 番の SMTP を使い続ける、と書いている
転送では、SMTP クライアントは宛先ドメインの MX レコードを引いて、配送先のホストを探す（RFC 5321 の Locating the Target Host 節）
MX にはポートを指定する手段が無いので、25 が常に使われる（RFC 8314 Section 7.3）

投稿との違い

投稿（587 / 465）：MUA が MSA に渡す。MSA は既定で SMTP AUTH による認証を要求する（RFC 6409 Section 4.3）
転送（25）：MTA が MX の指す宛先の MTA に渡す。MUA と MSA の間の話とは別の役割

暗号化

SMTP には、平文の接続を TLS に上げる STARTTLS 拡張がある（RFC 3207）
転送の SMTP は、TLS を「できれば使う」opportunistic（日和見）な方式を取る（RFC 7672 Section 1.3.1）
相手が TLS に対応していなければ、平文のまま送られることがある

👉 「25 は常に平文」ではない。ただし opportunistic なので、TLS が強制されるわけではない。補強の仕組みは章 6 で扱う。

❌「25 は古いので使わない」

サーバー同士の転送は、今も 25
投稿（クライアントからの送信）は、転送とは別の区間として 587 / 465 が用意されている

👉 クライアント（MUA やアプリ）から送るときは、25 ではなく投稿用の 587 / 465 を使うのが通常である（RFC 6409 Abstract は、投稿は通常 587 を使うとしている）。さらに RFC 8314 Section 4 は、25 番をユーザーの投稿に使っている MSP は、TLS（暗黙 TLS か STARTTLS）へできるだけ早く移行すべき（SHOULD）としている。

出典：

RFC 5321 Simple Mail Transfer Protocol（Receiving Strategy 節 / Locating the Target Host 節）：https://www.rfc-editor.org/rfc/rfc5321
RFC 3207 SMTP Service Extension for Secure SMTP over TLS（Abstract）：https://www.rfc-editor.org/rfc/rfc3207
RFC 7672 SMTP Security via Opportunistic DANE TLS（Section 1.3.1）：https://www.rfc-editor.org/rfc/rfc7672
RFC 6409（Abstract / Section 4.3）、RFC 8314（Section 4 / 7.3）は章 3 の出典と同じ

5. 受信：POP3 と IMAP

受信者の MUA が、メールボックス（メッセージストア）からメールを取り出す区間。
ここまでの投稿・転送とは別のプロトコルを使う。

プロトコル	ポート	暗号化の方式
POP3	110	平文で接続し、`STLS`（POP3 の STARTTLS 拡張）で TLS に切り替える
POP3	995	接続した直後から TLS（暗黙 TLS）
IMAP	143	平文で接続し、STARTTLS で TLS に切り替える
IMAP	993	接続した直後から TLS（暗黙 TLS）

ポートの根拠

POP3 は TCP 110 番で待ち受ける（RFC 1939 Section 3）
IMAP は、平文ポートの 143 か、暗黙 TLS のポートの 993 で待ち受ける（RFC 9051 Section 2.1）
995（pop3s）と 993（imaps）は、TCP 接続が確立した直後に TLS ハンドシェイクが始まる（RFC 8314 Section 3.1 / 3.2）
POP3 / IMAP の STARTTLS は RFC 2595 の拡張。コマンド名は IMAP が STARTTLS、POP3 が STLS
RFC 8314 も、POP / IMAP では暗黙 TLS を、平文ポートに繋いで STARTTLS（または同様のコマンド）で TLS に上げるより推奨している。STARTTLS 方式の文書として RFC 2595 を挙げている（RFC 8314 Section 1 / 3）
IMAP の STARTTLS は平文ポート側でだけ使える（RFC 9051 Section 6.2.1）

👉 POP3 の拡張を「POP3 の STARTTLS」と呼ぶことは多いが、実際に打つコマンドは STLS。

POP3 と IMAP の違い

POP3：サーバー上でメールを細かく操作する用途は想定していない。通常は、メールをダウンロードしてサーバーからは削除する（RFC 1939 Section 1）
IMAP：サーバー上のメールボックス（フォルダー）を、ローカルのフォルダーと機能的に同等に操作できる。オフラインのクライアントがサーバーと再同期することもできる（RFC 9051 Abstract）

「ダウンロード型」「同期型」という呼び方は RFC の用語ではなく、上の記述を要約した言い方である。

👉 複数の端末で同じメールボックスを見るなら IMAP。

出典：

RFC 1939 Post Office Protocol - Version 3（Section 1 / 3）：https://www.rfc-editor.org/rfc/rfc1939
RFC 9051 IMAP4rev2（Abstract / Section 2.1 / 6.2.1）：https://www.rfc-editor.org/rfc/rfc9051
RFC 2595 Using TLS with IMAP, POP3 and ACAP（IMAP STARTTLS 拡張 / POP3 STARTTLS 拡張）：https://www.rfc-editor.org/rfc/rfc2595
RFC 8314 Cleartext Considered Obsolete（Section 3.1 / 3.2）：https://www.rfc-editor.org/rfc/rfc8314

6. 暗号化方式で横断して整理する

ここまでの区間をまたいで、暗号化の方式は 3 段階に分けて整理できる。

平文：暗号化しない
STARTTLS：平文で接続し、途中で TLS に切り替える
暗黙 TLS：接続した直後から TLS（RFC 8314 では "Implicit TLS"）

方式	接続の始まり	該当するポート
平文	暗号化なし。TLS には上げない	25 / 587 / 110 / 143 で STARTTLS を使わなかった場合（暗黙 TLS の 465 / 995 / 993 では起きない）
STARTTLS	平文で始まり、`STARTTLS`（POP3 は `STLS`）で TLS に上げる	25 / 587 / 110 / 143
暗黙 TLS	接続の直後に TLS ハンドシェイクが始まる	465 / 995 / 993

👉 25 は「STARTTLS が使える」ポート。章 4 のとおり、転送では opportunistic（できれば使う）な方式で、強制ではない。

STARTTLS のダウングレード攻撃

STARTTLS は、平文で始めてから TLS に上げる。この構造には、弱点がある。

RFC 8461 は、SMTP の STARTTLS 応答（250 STARTTLS）を消せる攻撃者は、ダウングレード（downgrade）攻撃ができるとしている（RFC 8461 Section 1）
RFC 7672 も、サーバーが TLS に対応していることの表示は、中間者に簡単に消されてしまうとしている。その結果、接続を平文に下げられる（RFC 7672 Section 1.3.1 "STARTTLS Downgrade Attack"）

👉 この攻撃は一般に「STARTTLS ストリッピング」とも呼ばれる。ただしこれは通称で、RFC の用語は "downgrade" である。

RFC 8314 の推奨

投稿（SMTP Submission）と受信（POP / IMAP）では、平文ポートに繋いで STARTTLS で上げるより、暗黙 TLS を使うことを推奨している（RFC 8314 Section 1）
推奨の対象は MUA と MSP の間のプロトコルで、サーバー間の転送は対象外

👉 つまり表の暗黙 TLS の行（465 / 995 / 993）が、RFC 8314 が推奨する側。STARTTLS の行（587 / 110 / 143）が「使ってはいけない」という意味ではない。

25 番の暗号化を補強する仕組み

RFC 8314 Section 7.3 は、MX にはポートを指定する手段が無く、転送では 25 が常に使われる、と書いている
RFC 8314 は、転送の SMTP で TLS を使う話は扱っていない。「別のアプローチが必要」とし、例として RFC 7672 と MTA-STS を挙げている（RFC 8314 Section 1）

転送の暗号化を補強する仕組みとして、次の 2 つがある。詳細は本記事の範囲外とし、名前と役割だけ書く。

MTA-STS（RFC 8461）：受信側の事業者が「TLS で SMTP を受けられる」ことを宣言し、TLS を提供しない MX ホストへの配送を、送信側に拒否させるかを指定できる仕組み
DANE for SMTP（RFC 7672）：DNS の TLSA レコードに基づいて、MTA 間の SMTP 通信をダウングレード攻撃に強くする仕組み

出典：

RFC 8314 Cleartext Considered Obsolete（Section 1 / 7.3）：https://www.rfc-editor.org/rfc/rfc8314
RFC 8461 SMTP MTA Strict Transport Security（Abstract / Section 1）：https://www.rfc-editor.org/rfc/rfc8461
RFC 7672 SMTP Security via Opportunistic DANE TLS（Abstract / Section 1.3.1）：https://www.rfc-editor.org/rfc/rfc7672

7. ポート一覧表

章 3〜6 の内容を 1 枚にまとめる。表に新しい情報は足していない。

ポート	プロトコル	区間	暗号化	認証	根拠
25	SMTP	転送（MTA → MTA）	STARTTLS（相手が対応していれば。opportunistic）	投稿の SMTP AUTH とは別の役割（章 4）	RFC 5321 / RFC 3207 / RFC 7672
587	SMTP Submission（`submission`）	投稿（MUA → MSA）	平文で接続し、STARTTLS で TLS に切り替える	MSA は既定で SMTP AUTH による認証を要求する（章 3 の「認証」）	RFC 6409 / RFC 8314
465	SMTP Submission（`submissions`）	投稿（MUA → MSA）	暗黙 TLS	587 と同じ。MSA への要件（RFC 6409）がそのまま当てはまる（章 3 の「認証」）	RFC 8314
110	POP3	受信（MUA が取りに行く）	平文で接続し、`STLS` で TLS に切り替える	本文では扱わない（—）	RFC 1939 / RFC 2595
995	POP3（`pop3s`）	受信（MUA が取りに行く）	暗黙 TLS	本文では扱わない（—）	RFC 8314
143	IMAP	受信（MUA が取りに行く）	平文で接続し、STARTTLS で TLS に切り替える	本文では扱わない（—）	RFC 9051 / RFC 2595
993	IMAP（`imaps`）	受信（MUA が取りに行く）	暗黙 TLS	本文では扱わない（—）	RFC 9051 / RFC 8314

👉 暗号化の列で STARTTLS と書いたポート（25 / 587 / 110 / 143）は、STARTTLS を使わなければ平文のままになる。暗黙 TLS のポート（465 / 995 / 993）では起きない。

👉 RFC 8314 が推奨するのは、投稿と受信での暗黙 TLS。STARTTLS の行が「使ってはいけない」という意味ではない。

8. まとめ

ポート番号は「どの区間か」と「どの暗号化方式か」で決まる。クライアントが送るのは 587 / 465、サーバー同士の転送は 25、受け取るのは IMAP（143 / 993）か POP3（110 / 995）。

投稿（MUA → MSA）は 587 か 465。MSA は既定で SMTP AUTH を要求する
転送（MTA → MTA）は 25。TLS は opportunistic で、強制ではない
受信は IMAP か POP3。複数の端末で同じメールボックスを見るなら IMAP
暗号化は、平文・STARTTLS・暗黙 TLS の 3 段階。RFC 8314 が推奨するのは暗黙 TLS（465 / 995 / 993）
587 の STARTTLS も比較的広く使われており、「使ってはいけない」わけではない
587 と 465 で迷ったら、接続先が対応していれば 465（暗黙 TLS）。対応していなければ 587 で、TLS の確立を必須にして使う

👉 メールが届くかどうかや、なりすまし対策（SPF / DKIM / DMARC）はこちら：https://qiita.com/gtakairo/items/8df604e27d3bd4dea9dd

参考

RFC 5598 Internet Mail Architecture：https://www.rfc-editor.org/rfc/rfc5598
RFC 6409 Message Submission for Mail：https://www.rfc-editor.org/rfc/rfc6409
RFC 8314 Cleartext Considered Obsolete：https://www.rfc-editor.org/rfc/rfc8314
RFC 5321 Simple Mail Transfer Protocol：https://www.rfc-editor.org/rfc/rfc5321
RFC 3207 SMTP Service Extension for Secure SMTP over TLS：https://www.rfc-editor.org/rfc/rfc3207
RFC 7672 SMTP Security via Opportunistic DANE TLS：https://www.rfc-editor.org/rfc/rfc7672
RFC 8461 SMTP MTA Strict Transport Security：https://www.rfc-editor.org/rfc/rfc8461
RFC 1939 Post Office Protocol - Version 3：https://www.rfc-editor.org/rfc/rfc1939
RFC 9051 IMAP4rev2：https://www.rfc-editor.org/rfc/rfc9051
RFC 2595 Using TLS with IMAP, POP3 and ACAP：https://www.rfc-editor.org/rfc/rfc2595
IANA Service Name and Transport Protocol Port Number Registry：https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml