Submission（ポート587）とは何ですか？

Submission（ポート587）は、メールクライアントからメールサーバーへメールを送信するための専用ポートです。RFC 6409で定義され、SMTP AUTH（認証）とSTARTTLS（暗号化）を必須とし、ポート25（MTA間配送用）と役割を分離しています。ISPによるポート25ブロック（OP25B）の対策としても重要です。

Postfixでのsubmission設定は？

master.cfでsubmission行のコメントを解除し、smtpd_sasl_auth_enable=yes、smtpd_tls_security_level=encryptを設定します。SASL認証にはDovecotバックエンドの使用が一般的です。ポート465も有効にする場合はsmtps行も設定します。

Submission（ポート587） | 用語集 | IT/AIエンジニア　野口真一

Q: ポート587と465の違いは？

ポート587はSTARTTLSで暗号化にアップグレードする方式、ポート465（Submissions）は接続開始時から暗黙的TLSで暗号化する方式です。RFC 8314では暗黙的TLS（ポート465）が推奨されていますが、ポート587も広く使用されています。両方とも認証が必須です。

Q: メールクライアントの設定を自動化する方法はありますか？

RFC 6186で定義されたDNS SRVレコード（_submission._tcpなど）を用意しておくと、対応するメールクライアントがサーバー情報を自動検出できます。ただし対応状況はクライアントによって異なります。

この用語をシェア

Facebook X (Twitter)

Submissionとは

Submission（メール投稿）は、メールクライアントからメールサーバーへメールを送り込む段階を指すプロトコル上の役割であり、その受け口として使われる専用ポートがポート587です。1998年にRFC 2476として最初に標準化され、2006年に改訂版のRFC 6409に置き換わりました。IANAのポート登録名は「submission」で、SMTP（Simple Mail Transfer Protocol）の拡張仕様であるESMTPをベースに、クライアントからの投稿という用途に特化した振る舞いを追加したものです。

ポート25が本来「メールサーバー同士がメールを転送し合う（MTA間リレー）」ためのポートであるのに対し、ポート587は「メールクライアント（MUA: Mail User Agent）がメールサーバー（MSA: Message Submission Agent）に対してメールを投稿する」ための入り口という点が本質的な違いです。役割が明確に分かれているからこそ、SMTP AUTHによる送信者認証とSTARTTLSによる通信の暗号化を必須にできる、という設計になっています。

1990年代後半から2000年代にかけて、認証なしで誰でも中継できる「オープンリレー」を悪用したスパムメールが社会問題化しました。これを受けて、多くのISP（インターネットサービスプロバイダ）が一般利用者回線からのポート25宛て通信を遮断するOP25B（Outbound Port 25 Blocking）を導入しました。この対策と両立させる形で、認証済みユーザーのみが使える専用の投稿口としてポート587が普及していった、という歴史的経緯があります。現在では、Gmail・Microsoft 365・独自ドメインのメールサーバーを問わず、メールクライアントの送信設定は基本的にポート587（または465）を指定するのが標準になっています。

Submissionの仕組み

Submissionは通信手順そのものはSMTP（ESMTP）と同じコマンド体系（EHLO、MAIL FROM、RCPT TO、DATA等）を使いますが、接続直後の振る舞いに明確なポリシーが課されています。典型的なセッションの流れは以下の通りです。

クライアント → mail.example.com:587 へTCP接続
S: 220 mail.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-mail.example.com
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
C: STARTTLS                      ← 暗号化通信へアップグレード要求
S: 220 2.0.0 Ready to start TLS
   ---- TLSハンドシェイク ----
C: EHLO client.example.com       ← 暗号化後に再度EHLO
S: 250-mail.example.com
S: 250 AUTH PLAIN LOGIN
C: AUTH PLAIN AGluZm9AZXhhbXBsZS5jb20AcGFzc3dvcmQ=
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<info@example.com>
S: 250 2.1.0 Ok
C: RCPT TO:<dest@example.jp>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: （メール本文）
C: .
S: 250 2.0.0 Ok: queued as 3F2A1B2C

ポイントは、STARTTLSで暗号化してからでなければAUTHコマンドを受け付けない運用が一般的であること、そして認証が成功するまでMAIL FROM以降のコマンドを一切受け付けないことです。受け付けたメールサーバー（MSA）は、認証されたアカウントとエンベロープ送信者（MAIL FROM）が一致しているかを検証（Postfixでいうreject_sender_login_mismatch）した上で、Receivedヘッダーを付与してキューに投入し、その後はポート25経由のMTA間リレーとして宛先ドメインへ配送していきます。つまりSubmission（587）は「入り口の受付」、ポート25は「サーバー間の配送」という、パイプラインの前段と後段の関係にあります。

ポート25との違い

項目	ポート587（Submission）	ポート25（SMTP）
用途	クライアントからサーバーへの投稿	サーバー間通信
認証	必須（SMTP AUTH）	オプション
暗号化	STARTTLS推奨	オプション
ISPブロック	されにくい	される可能性が高い

セキュリティ機能

SASL認証: ユーザー名・パスワード認証
STARTTLS: 暗号化通信の開始
レート制限: スパム送信の防止
送信者検証: 送信者アドレスの確認

Postfixの場合、この「認証必須」「暗号化必須」というポリシーはmaster.cfのsubmissionエントリでsmtpd_sasl_auth_enable=yesとsmtpd_tls_security_level=encryptを組み合わせることで実現します。さらにsmtpd_client_restrictions=permit_sasl_authenticated,rejectを指定すれば「認証済みでなければ即座に拒否」という厳格な運用になり、未認証の踏み台利用を構造的に防げます。加えて、smtpd_client_message_rate_limitやanvil_rate_time_unitといったパラメータで1クライアントあたりの単位時間送信数を制限し、乗っ取られたアカウントからの大量送信（スパム化）を早期に頭打ちさせる運用も定石です。

具体例・ユースケース

Submission（587）が実際にどこで使われているか、具体的な場面で見ていきます。

1. メールクライアントの送信設定

Outlook、Thunderbird、Apple Mail、スマートフォンの標準メールアプリなど、いわゆるMUA（Mail User Agent）から独自ドメインのメールアドレスで送信する場合、送信サーバー（SMTP）の設定でポート587を指定します。典型的な設定値は次の通りです。

項目	設定値の例
送信サーバー（SMTP）	mail.example.com
ポート	587
暗号化方式	STARTTLS
認証方式	通常のパスワード認証または OAuth2.0
ユーザー名	info@example.com（フルアドレス指定が一般的）

2. 複数デバイス・複数拠点からの送信

会社のデスクトップPC、自宅のノートPC、外出先のスマートフォンなど、同じメールアカウントを複数の端末・複数の回線から使う場合でも、Submissionは認証さえ通ればどの回線からでも同じように送信できます。ポート25のように送信元IPのレピュテーション（評判）に左右されにくく、アカウント単位で送信可否を管理できる点が実務上のメリットです。

3. アプリケーション・SaaSからの通知メール送信

WordPressのSMTPプラグイン、業務システムのバッチ処理、複合機のスキャン結果送信機能など、人が直接操作しないシステムからのメール送信にもSubmissionが使われます。多くのWordPress用SMTPプラグインの設定画面では「SMTPホスト」「ポート587」「暗号化：STARTTLS」「ユーザー名・パスワード」を入力する項目が並んでおり、これはまさに本ページで解説しているSubmissionの設定そのものです。

4. メールクライアントの自動設定（オートコンフィグ）

ThunderbirdなどのMUAには、メールアドレスとパスワードを入力するだけでサーバー情報を自動検出する機能があります。この自動検出の手段の一つとして、RFC 6186で定義されたDNS SRVレコードを使う方式があります。ドメイン側に次のようなレコードを用意しておくと、クライアントが自動的にSubmissionサーバーとポートを見つけられます。

; RFC 6186に基づくメール送信サーバーの自動検出用SRVレコード
_submission._tcp.example.com.  IN SRV 0 1 587 mail.example.com.
_imap._tcp.example.com.        IN SRV 0 1 143 mail.example.com.
_imaps._tcp.example.com.       IN SRV 0 1 993 mail.example.com.

形式は「優先度重みポート番号ホスト名」で、この例では優先度0・重み1でmail.example.comの587番ポートをSubmissionサーバーとして案内しています。すべてのメールクライアントが対応しているわけではありませんが、社内向けメール設定手順書を簡略化したい場合に選択肢の一つになります。

メリット・デメリット（注意点）

メリット

第三者中継（オープンリレー）の防止: 認証済みユーザーしか送信できないため、外部から勝手に中継利用される事故を構造的に防げる
ISPによるポート25ブロック（OP25B）を回避できる: 一般家庭回線やモバイル回線からでも安定して送信できる
盗聴・改ざんの防止: STARTTLS必須運用により、認証情報や本文が平文で流れるリスクを減らせる
送信者なりすましの一次防止: reject_sender_login_mismatch等の設定により、認証アカウントと異なるFromアドレスでの送信を拒否できる
送信ログによる追跡性の向上: 「いつ・どのアカウントが・どこから送信したか」がログに残るため、インシデント発生時の調査がしやすい

デメリット・注意点

認証情報が漏えいするとアカウントごと踏み台化される: パスワードが流出すると、正規の投稿口を悪用した大量スパム送信の起点になり得る。ブルートフォース攻撃（総当たり）の標的にもなりやすいため、fail2ban等での自動遮断が事実上必須
古いクライアント・機器との互換性問題: STARTTLSやAUTH PLAIN/LOGINに対応していない古い複合機やレガシーシステムでは、追加の互換設定や機器の更新が必要になる場合がある
OAuth移行に伴う設定変更コスト: GmailやMicrosoft 365ではパスワード認証（Basic認証）が段階的に廃止されており、既存のシステム連携をOAuth 2.0（XOAUTH2）へ作り直す手間が発生する
アプリケーションパスワードの管理負担: 2要素認証を有効にしたアカウントでSubmissionを使う場合、通常のログインパスワードとは別の「アプリパスワード」を発行・管理する運用が必要になることが多い
証明書の期限切れによる送信停止リスク: STARTTLS用のTLS証明書が失効すると送信自体が失敗するため、Let's Encrypt等を使う場合は自動更新の仕組みを必ず組み込む必要がある

混同されやすい用語・類似技術との違い

Submissionは「ポート587」という表面的な理解だけだと、近縁の用語と混同しやすい概念です。代表的な混同ポイントを整理します。

用語	ポート	Submissionとの違い
SMTP（ポート25）	25	MTA間のサーバー間配送用。クライアントからの投稿を想定しておらず、認証は必須ではない
Submissions（ポート465）	465	用途はSubmissionと同じくクライアント投稿だが、接続直後から暗黙的TLS（Implicit TLS）で始まる点が異なる。RFC 8314で推奨方式とされている
ポート2525	2525	IANAに正式登録された用途ではなく、一部のクラウドやSaaSがOP25B・587ブロック環境の代替として非公式に開放しているポート。標準ではないため利用可否はサービスごとに確認が必要
MSA（Message Submission Agent）	-	Submissionを受け付けるサーバー機能そのものの名称。ポート587はMSAが待ち受けるポート番号であり、「MSA＝仕組み」「587＝入口」という関係
MTA（Message Transfer Agent）	25	サーバー間でメールをリレーする役割。Postfix・Sendmail・Eximなどのソフトウェアは、MSAとMTAの両方の機能を1つのプロセス群で兼ねていることが多い
IMAP/POP3	143/993, 110/995	メールを「受信・閲覧」するためのプロトコル。Submissionは送信専用であり、役割が正反対

特に混同しやすいのが「Submission（587・STARTTLS）」と「Submissions（465・暗黙的TLS）」の呼称の近さです。前者はRFC 6409で定義された歴史的な標準、後者はRFC 8314で追認された方式で、末尾の「s」の有無で区別されます。どちらも「クライアントからサーバーへの認証済み投稿」という目的は同じであり、暗号化を開始するタイミング（コマンドで昇格するか、最初から暗号化されているか）が違うだけ、という点を押さえておくと混乱しません。

自社メールサーバー運用への応用

Postfixでの設定例

# master.cf - Submission設定
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_sender_restrictions=reject_sender_login_mismatch
  -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,permit_sasl_authenticated,reject

Docker Mailserverでの設定

Docker Mailserverでは、Submission設定がデフォルトで有効になっています：

services:
  mailserver:
    environment:
      - ENABLE_SASLAUTHD=1
      - SSL_TYPE=letsencrypt
    ports:
      - "587:587"  # Submission
      - "465:465"  # SMTPS（オプション）

メールクライアント設定例

サーバー: mail.example.com
ポート: 587
暗号化: STARTTLS
認証: ユーザー名・パスワード

Dovecotとの連携（SASL認証バックエンド）

Postfix単体にはユーザー名・パスワードを検証するデータベース機能がないため、実務ではDovecotのSASL機能をバックエンドとして使うのが定石です。Postfix側からDovecotのUNIXソケットを参照する設定は次のようになります。

# /etc/postfix/main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

# /etc/dovecot/conf.d/10-master.conf
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
}

こうしておくと、IMAP/POP3のログイン認証とSubmission（SMTP AUTH）の認証を同じユーザーDB（passdb/userdb）で一元管理でき、パスワード変更やアカウント無効化の運用が一箇所で完結します。

ブルートフォース対策（fail2ban）

ポート587は世界中からの認証試行の標的になりやすいポートです。Postfixのログを監視し、認証失敗を繰り返すIPを自動遮断するfail2banの設定例は次の通りです。

# /etc/fail2ban/jail.local
[postfix-sasl]
enabled  = true
port     = smtp,465,submission
filter   = postfix-sasl
logpath  = /var/log/mail.log
maxretry = 5
bantime  = 3600
findtime = 600

maxretry（許容回数）とfindtime（監視時間）を絞りすぎると正規ユーザーの一時的な入力ミスまで遮断してしまうため、社内の利用実態に合わせて閾値を調整することが重要です。

ファイアウォールでの公開範囲の制御

Submissionポートは外部の一般ユーザーが使う前提で全世界に開放するのが基本ですが、社内専用メールサーバーなど利用者が限定される場合は、送信元を絞ることでブルートフォースの母数自体を減らせます。

# ufwの例：社内ネットワークとVPNセグメントのみ587番ポートを許可
ufw allow from 203.0.113.0/24 to any port 587 proto tcp
ufw allow from 198.51.100.0/24 to any port 587 proto tcp

まとめ

Submission（ポート587）は、クライアントからのメール送信に特化した安全な投稿口です。RFC 6409で標準化され、SMTP AUTHによる認証とSTARTTLSによる暗号化を前提とした設計により、オープンリレー悪用やなりすまし、盗聴のリスクを構造的に減らしています。ポート25（サーバー間配送）・ポート465（Submissions、暗黙的TLS）・ポート2525（非公式代替）といった近縁のポートとは役割や標準化の位置づけが異なるため、混同せずに使い分けることが重要です。

自社メールサーバーを構築・運用する際は、Postfixのsubmissionエントリでの認証・暗号化必須化、Dovecotとの認証連携、fail2banによるブルートフォース対策、証明書の自動更新という一連の設定を漏れなく行うことが、安定運用の実務ポイントになります。Gmail・Microsoft 365をはじめとする主要サービスがOAuth 2.0認証への移行を進めている流れを踏まえ、自社システムの認証方式も継続的に見直していく姿勢が求められます。

2025-2026年の最新動向

暗黙的TLS（ポート465）の復権が進んでいます。RFC 8314でSubmissions（ポート465、暗黙的TLS）が正式に推奨され、主要メールクライアント・サーバーが対応を完了しています。STARTTLSはネゴシエーション途中で平文にダウングレードさせる中間者攻撃（STARTTLSストリッピング）の理論的リスクが指摘されており、最初から暗号化されている465方式の方が構造的に安全とされる傾向が強まっています。とはいえ既存システムとの互換性の関係で587も引き続き広く使われており、当面は両方式が併存する状況が続くとみられます。

OAuth 2.0認証への移行が進み、Gmail・Microsoft 365ではパスワードのみによるSMTP認証（Basic認証）の廃止が進められており、OAuth 2.0（XOAUTH2/OAUTHBEARER）への切り替えが求められる場面が増えています。自社構築のメールサーバーでOAuth 2.0を導入する場合は、PostfixやDovecotが標準で対応しているわけではないため、対応するプラグインや外部認証サーバーとの連携を追加検討する必要があります。

OP25Bの定着とSubmission利用の一般化により、個人・企業を問わずSubmissionポート（587/465）を経由した送信が事実上の標準となっています。あわせて、送信ドメイン認証（SPF・DKIM・DMARC）の設定状況をGmail・Yahoo!等の大手メールプロバイダが重視する傾向が強まっており、Submissionでの認証・暗号化に加えて送信ドメイン側の認証設定も合わせて整備しないと、正しく認証送信していてもメールが迷惑メール判定されるケースが増えている点には注意が必要です。

よくある質問（FAQ）

Q. Submission（ポート587）とは？

メールクライアントからサーバーへの送信専用ポートです。認証と暗号化が必須で、ポート25と役割が分離されています。

Q. ポート587と465の違いは？

587はSTARTTLSで暗号化アップグレード、465は最初から暗黙的TLSです。RFC 8314では465が推奨されています。

Q. Postfixでの設定方法は？

master.cfのsubmission行を有効化し、SASL認証とTLS暗号化を設定します。Dovecotバックエンドとの連携が一般的です。

Q. ポート587とポート2525の違いは？

2525はIANAに正式登録された用途ではなく、一部のクラウド事業者やSaaSがOP25Bやポートブロックの代替として非公式に開放しているポートです。標準化されていないため、利用できるかどうかはサービスごとに確認する必要があります。

Q. Submissionを使うメリット・デメリットは？

メリットは第三者中継の防止、ISPのポート25ブロック回避、盗聴防止、送信ログによる追跡性向上です。デメリットは認証情報漏えい時の踏み台化リスクやブルートフォース攻撃の標的になりやすい点で、fail2ban等の対策が実務上ほぼ必須になります。

Q. メールクライアントの設定を自動化する方法はありますか？

RFC 6186で定義されたDNS SRVレコード（_submission._tcpなど）を用意しておくと、対応するメールクライアントがサーバー情報を自動検出できます。ただし対応状況はクライアントによって異なります。

外部リンク

この用語についてもっと詳しく

Submissionに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。

お問い合わせサービス一覧

Submission（ポート587）